Re: [PATCH] can: af_can: Fix Spectre v1 vulnerability
After *trying* to follow the discussion on ... https://marc.info/?l=linux-kernel=154554485324143=2 [PATCH] net: core: Fix Spectre v1 vulnerability ... I'm still not sure whether af_can.c needs this enhancement or not. Just waiting for the end of the discussion :-) Thanks to the experts! Oliver On 12/21/18 10:22 PM, Gustavo A. R. Silva wrote: protocol is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: net/can/af_can.c:115 can_get_proto() warn: potential spectre issue 'proto_tab' [w] Fix this by sanitizing protocol before using it to index proto_tab. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel=152449131114778=2 Signed-off-by: Gustavo A. R. Silva --- net/can/af_can.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/can/af_can.c b/net/can/af_can.c index 1684ba5b51eb..cade7250c6d4 100644 --- a/net/can/af_can.c +++ b/net/can/af_can.c @@ -59,6 +59,7 @@ #include #include #include +#include #include #include @@ -136,6 +137,7 @@ static int can_create(struct net *net, struct socket *sock, int protocol, if (protocol < 0 || protocol >= CAN_NPROTO) return -EINVAL; + protocol = array_index_nospec(protocol, CAN_NPROTO); cp = can_get_proto(protocol);
Re: [PATCH v1] cpufreq: qcom: Read voltage LUT and populate OPP
Hello Matthias,
Thanks for your review comments.
On 12/22/2018 2:27 AM, Matthias Kaehlcke wrote:
Hi Taniya,
On Fri, Dec 21, 2018 at 11:36:48PM +0530, Taniya Das wrote:
Add support to read the voltage look up table and populate OPP for all
corresponding CPUS.
Signed-off-by: Taniya Das
---
drivers/cpufreq/qcom-cpufreq-hw.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d83939a..7559b87 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -10,18 +10,21 @@
#include
#include
#include
+#include
#include
#define LUT_MAX_ENTRIES 40U
#define LUT_SRC GENMASK(31, 30)
#define LUT_L_VAL GENMASK(7, 0)
#define LUT_CORE_COUNTGENMASK(18, 16)
+#define LUT_VOLT GENMASK(11, 0)
#define LUT_ROW_SIZE 32
#define CLK_HW_DIV2
/* Register offsets */
#define REG_ENABLE0x0
-#define REG_LUT_TABLE 0x110
+#define REG_FREQ_LUT_TABLE 0x110
+#define REG_VOLT_LUT_TABLE 0x114
The new names suggest that there is a LUT for frequencies and another
one for voltages. I don't have access to hardware documentation, but
from the code and offsets in this driver it seems there is a single
table at offset 0x110, with a 'row' of 32 bytes per OPP. Within this
row the frequency (and other values) is located at offset 0, the
voltage at offset 4.
I'd suggest to keep REG_LUT_TABLE, add a define LUT_OFFSET_VOLTAGE/MV
(or similar) and adjust the math in qcom_cpufreq_hw_read_lut() to use
REG_LUT_TABLE as base offset.
These names are as per HW documentation and the math is kept as per the
documentation for reading the voltage.
#define REG_PERF_STATE0x920
static unsigned long cpu_hw_rate, xo_rate;
@@ -75,19 +78,26 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
void __iomem *base)
{
u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, freq;
+ u32 volt;
unsigned int max_cores = cpumask_weight(policy->cpus);
struct cpufreq_frequency_table *table;
+ unsigned long cpu_r;
nit: why 'cpu_r' and not just 'cpu'?
(if it is needed at all, see my comment below)
table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
if (!table)
return -ENOMEM;
for (i = 0; i < LUT_MAX_ENTRIES; i++) {
- data = readl_relaxed(base + REG_LUT_TABLE + i * LUT_ROW_SIZE);
+ data = readl_relaxed(base + REG_FREQ_LUT_TABLE +
+ i * LUT_ROW_SIZE);
src = FIELD_GET(LUT_SRC, data);
lval = FIELD_GET(LUT_L_VAL, data);
core_count = FIELD_GET(LUT_CORE_COUNT, data);
+ data = readl_relaxed(base + REG_VOLT_LUT_TABLE +
+ i * LUT_ROW_SIZE);
+ volt = FIELD_GET(LUT_VOLT, data) * 1000;
+
if (src)
freq = xo_rate * lval / 1000;
else
@@ -123,6 +133,10 @@ static int qcom_cpufreq_hw_read_lut(struct device *dev,
prev_cc = core_count;
prev_freq = freq;
+
+ freq *= 1000;
+ for_each_cpu(cpu_r, policy->cpus)
+ dev_pm_opp_add(get_cpu_device(cpu_r), freq, volt);
Are you sure we want to duplicate the OPP entries for all CPUs in the
cluster? IIUC the frequencies of the cores in a cluster can't be
changed individually, hence the cores should have a shared table. I
think dev_pm_opp_get_sharing_cpus() does what you need.
You currently also add OPPs for invalid frequencies. From my SDM845
device:
cat /sys/devices/system/cpu/cpufreq/policy4/scaling_available_freq
=> 825600 902400 979200 1056000 1209600 1286400 1363200 1459200
1536000 1612800 1689600 1766400 1843200 192 1996800 2092800
2169600 2246400 2323200 240 2476800 2553600 2649600
cat /sys/devices/system/cpu/cpufreq/policy4/scaling_boost_frequencies
2803200
ls /sys/kernel/debug/opp/cpu4/
opp:105600 opp:161280 opp:209280 opp:255360 opp:82560
opp:120960 opp:168960 opp:216960 opp:264960 opp:90240
opp:128640 opp:176640 opp:224640 opp:270720 opp:97920
opp:136320 opp:184320 opp:232320 opp:276480
opp:145920 opp:192000 opp:24 opp:278400
opp:153600 opp:199680 opp:247680 opp:280320
There are OPP entries for 270720, 276480 and 278400 Hz,
however these frequencies appear neither in available_frequencies nor
boost_frequencies.
}
Could you help validating with the patch below?
Re: [PATCH] sock: Make sock->sk_tstamp thread-safe
On Sat, Dec 22, 2018 at 11:31 PM Eric Dumazet wrote: > > > > On 12/21/2018 12:27 PM, Deepa Dinamani wrote: > > Al Viro mentioned that there is probably a race condition > > lurking in accesses of sk_tstamp on 32-bit machines. > > > > sock->sk_tstamp is of type ktime_t which is always an s64. > > On a 32 bit architecture, we might run into situations of > > unsafe access as the access to the field becomes non atomic. > > > > Use seqlocks for synchronization. > > This allows us to avoid using spinlocks for readers as > > readers do not need mutual exclusion. > > > > Hi Deepa > > Please come up with something that has zero added costs for 64bit kernels. > > Most of us do not really care about 32bit kernels anymore, so we do not want > to slow > down 64bits kernels for such things. > > Look at include/linux/u64_stats_sync.h for initial thoughts. This is similar to what I did here. But, I can add a few ifdef's to make this code a noop on 64 bit arches. I will include this in my next update. I'm assuming there is no contention on whether writers need exclusive access and hence requiring a lock here. Let me know otherwise. Thanks, Deepa
Re: [PATCH v9 00/13] arch/resctrl: AMD QoS support
On Nov 21 2018 20:28:23, Moger, Babu wrote:
>
>This series adds support for AMD64 architectural extensions for
>Platform Quality of Service.
The term "QoS" is already used for net/sched/. It will be bad naming to
have QoS - and then an AMD QoS / Platform QoS as well. Preexisting,
decade-old howtos may speak of enabling "QoS", and with the ambiguity,
the unsuspecting kernel builder apprentice may enable the wrong thing in
his config.
So either the QoS from networking gets correspondingly renamed ("packet
QoS"?.. or something), or else AMD QoS should be changed.
[vfs] cbc815d9ce: BUG:unable_to_handle_kernel
FYI, we noticed the following commit (built with gcc-6):
commit: cbc815d9ce7ae30677c929e94b2e176d5f4a5a36 ("vfs: Simplify security mount
option processing")
https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git
mount-cleanups-testing
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 768M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | e06ef473d1 | cbc815d9ce |
+--+++
| boot_successes | 4 | 0 |
| boot_failures| 0 | 4 |
| BUG:unable_to_handle_kernel | 0 | 4 |
| Oops:#[##] | 0 | 4 |
| RIP:join_options | 0 | 4 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 4 |
+--+++
[2.150318] BUG: unable to handle kernel NULL pointer dereference at
0010
[2.153661] PGD 0 P4D 0
[2.153661] Oops: 0002 [#1] PTI
[2.153661] CPU: 0 PID: 0 Comm: swapper Not tainted
4.20.0-rc1-00054-gcbc815d #1
[2.153661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[2.153661] RIP: 0010:join_options+0x7c/0x85
[2.153661] Code: f6 74 27 4c 89 c9 48 89 f7 f2 ae 48 f7 d1 48 ff c9 4c 39
c2 74 06 c6 02 2c 48 ff c2 48 89 d7 48 83 c3 08 f3 a4 48 89 fa eb d1 02 00
4c 89 c0 5b 5d c3 31 c0 48 39 b7 f8 05 00 00 55 48 89 e5
[2.153661] RSP: :81e03da8 EFLAGS: 00010246
[2.153661] RAX: RBX: 8802fae8 RCX:
[2.153661] RDX: 0010 RSI: RDI:
[2.153661] RBP: 81e03db0 R08: 0010 R09:
[2.153661] R10: 81e03dc0 R11: R12:
[2.153661] R13: R14: 81e03e08 R15:
[2.153661] FS: () GS:81e38000()
knlGS:
[2.153661] CS: 0010 DS: ES: CR0: 80050033
[2.153661] CR2: 0010 CR3: 01e1a000 CR4: 06b0
[2.153661] Call Trace:
[2.153661] security_parse_options+0x4d/0x9e
[2.153661] mount_fs+0x4e/0xad
[2.153661] vfs_kern_mount+0x63/0x147
[2.153661] mnt_init+0x1b2/0x25d
[2.153661] vfs_caches_init+0x7d/0xa8
[2.153661] start_kernel+0x5b3/0x63e
[2.153661] x86_64_start_reservations+0x88/0xa9
[2.153661] x86_64_start_kernel+0x78/0x9b
[2.153661] secondary_startup_64+0xa4/0xb0
[2.153661] Modules linked in:
[2.153661] CR2: 0010
[2.153661] random: get_random_bytes called from init_oops_id+0x21/0x32 with
crng_init=0
[2.153661] ---[ end trace b408251ec522a787 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.20.0-rc1 Kernel Configuration
#
#
# Compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=60400
CONFIG_CLANG_VERSION=0
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_DEBUGFS=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
[PATCH] ARM: OMAP: DTS: N950/N9: fix onenand timings
Commit a758f50f10cf ("mtd: onenand: omap2: Configure driver from DT")
started using DT specified timings for GPMC, and as a result the
OneNAND stopped working on N950/N9 as we had wrong values in the DT.
Fix by updating the values to bootloader timings that have been tested
to be working on both Nokia N950 and N9.
Fixes: a758f50f10cf ("mtd: onenand: omap2: Configure driver from DT")
Signed-off-by: Aaro Koskinen
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 42 ++--
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 0d9b85317529..e142e6c70a59 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -370,6 +370,19 @@
compatible = "ti,omap2-onenand";
reg = <0 0 0x2>;/* CS0, offset 0, IO size 128K */
+ /*
+* These timings are based on CONFIG_OMAP_GPMC_DEBUG=y reported
+* bootloader set values when booted with v4.19 using both N950
+* and N9 devices (OneNAND Manufacturer: Samsung):
+*
+* gpmc cs0 before gpmc_cs_program_settings:
+* cs0 GPMC_CS_CONFIG1: 0xfd001202
+* cs0 GPMC_CS_CONFIG2: 0x00181800
+* cs0 GPMC_CS_CONFIG3: 0x00030300
+* cs0 GPMC_CS_CONFIG4: 0x18001804
+* cs0 GPMC_CS_CONFIG5: 0x03171d1d
+* cs0 GPMC_CS_CONFIG6: 0x9708
+*/
gpmc,sync-read;
gpmc,sync-write;
gpmc,burst-length = <16>;
@@ -379,26 +392,27 @@
gpmc,device-width = <2>;
gpmc,mux-add-data = <2>;
gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <87>;
- gpmc,cs-wr-off-ns = <87>;
+ gpmc,cs-rd-off-ns = <122>;
+ gpmc,cs-wr-off-ns = <122>;
gpmc,adv-on-ns = <0>;
- gpmc,adv-rd-off-ns = <10>;
- gpmc,adv-wr-off-ns = <10>;
- gpmc,oe-on-ns = <15>;
- gpmc,oe-off-ns = <87>;
+ gpmc,adv-rd-off-ns = <15>;
+ gpmc,adv-wr-off-ns = <15>;
+ gpmc,oe-on-ns = <20>;
+ gpmc,oe-off-ns = <122>;
gpmc,we-on-ns = <0>;
- gpmc,we-off-ns = <87>;
- gpmc,rd-cycle-ns = <112>;
- gpmc,wr-cycle-ns = <112>;
- gpmc,access-ns = <81>;
+ gpmc,we-off-ns = <122>;
+ gpmc,rd-cycle-ns = <148>;
+ gpmc,wr-cycle-ns = <148>;
+ gpmc,access-ns = <117>;
gpmc,page-burst-access-ns = <15>;
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,wait-monitoring-ns = <0>;
- gpmc,clk-activation-ns = <5>;
- gpmc,wr-data-mux-bus-ns = <30>;
- gpmc,wr-access-ns = <81>;
- gpmc,sync-clk-ps = <15000>;
+ gpmc,clk-activation-ns = <10>;
+ gpmc,wr-data-mux-bus-ns = <40>;
+ gpmc,wr-access-ns = <117>;
+
+ gpmc,sync-clk-ps = <15000>; /* TBC; Where this value came? */
/*
* MTD partition table corresponding to Nokia's MeeGo 1.2
--
2.17.0
Re: FYI: Userland breakage caused by udev bind commit
On Sun, Dec 23, 2018 at 06:17:04PM +0100, Christian Brauner wrote:
> On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote:
> > Hi,
> >
> > I am the maintainer of libmtp and libgphoto2
> >
> > Some months ago I was made aware of this bug:
> > https://bugs.kde.org/show_bug.cgi?id=387454
> >
> > This was fallout identified to come from this kernel commit:
> >
> > commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
> > Author: Dmitry Torokhov
> > Date: Wed Jul 19 17:24:30 2017 -0700
>
> Fwiw, the addition of {un}bind events has caused issues for
> systemd-udevd as well and is tracked here:
> https://github.com/systemd/systemd/issues/7587
> I haven't been aware of this until yesterday and it seems that so far
> this hasn't been brought up on lkml until you did now.
The fallout was caused by premature enabling of the new events in
systemd/udev by yours truly (even though the commit has Lennart's name
on it due to how it was merged):
https://github.com/systemd/systemd/commit/9a39e1ce314d1a6f8a754f6dab040019239666a9
"Add handling for bind/unbind actions (#6720)
Newer kernels will emit uevents with "bind" and "unbind" actions. These
uevents will be issued when driver is bound to or unbound from a device.
"Bind" events are helpful when device requires a firmware to operate
properly, and driver is unable to create a child device before firmware
is properly loaded.
For some reason systemd validates actions and drops the ones it does not
know, instead of passing them on through as old udev did, so we need to
explicitly teach it about them."
Similarly it is now papered over in systemd/udev until we make it
properly handle new events:
https://github.com/systemd/systemd/commit/56c886dc7ed5b2bb0882ba85136f4070545bfc1b
"sd-device: ignore bind/unbind events for now
Until systemd/udev are ready for the new events and do not flush entire
device state on each new event received, we should ignore them."
> >
> > If distributions would be using libmtp and libgphoto2 udev rules
> > that just triggered on "add" events, and not the new "bind" events,
> > the missing "attribute tagging" of the "bind" events would confused the
> > KDE Solid device detection and make the devices no longer detected.
> >
> > This did not affect distributions that rely on the newer "hwdb"
> > device detection method.
> >
> > I have released fixed libmtp and libgphoto2 versions in November, so
> > this is under control, but wanted to bring this up as a "kernel caused
> > userland breakage".
Given that we explicitly enabled these new events in systemd/udev code
this is actually "userspace caused userspace breakage" case.
Still it is unfortunate that we did nit notice that my patch enabling
this functionality in systemd was premature.
Thanks.
--
Dmitry
[char-misc-next] mei: squash single_recv_buf into one bit in client properties
From: Alexander Usyskin
single_recv_buf member of struct mei_client_properties has a boolean
value and can be represented in on bit, to free other 7 bits
for another usage.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 2b7f7677f8cc..b7d2487b8409 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -311,7 +311,8 @@ struct mei_client_properties {
u8 protocol_version;
u8 max_number_of_connections;
u8 fixed_address;
- u8 single_recv_buf;
+ u8 single_recv_buf:1;
+ u8 reserved:7;
u32 max_msg_length;
} __packed;
--
2.20.1
Re: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver
Hi, Here are a few Kconfig text corrections. On 12/23/18 7:13 AM, Pawel Laszczak wrote: > diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig > new file mode 100644 > index ..4adfd87811e8 > --- /dev/null > +++ b/drivers/usb/cdns3/Kconfig > @@ -0,0 +1,44 @@ > +config USB_CDNS3 > + tristate "Cadence USB3 Dual-Role Controller" > + depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA > + help > + Say Y here if your system has a cadence USB3 dual-role controller. > + It supports: dual-role switch, Host-only, and Peripheral-only. > + > + If you choose to build this driver is a dynamically linked as > + module, the module will be called cdns3.ko. > + > +if USB_CDNS3 > + > +config USB_CDNS3_GADGET > +bool "Cadence USB3 device controller" > +depends on USB_GADGET > +help > + Say Y here to enable device controller functionality of the > + cadence USBSS-DEV driver. > + > + This controller supports FF, HS and SS mode. It doesn't support > + LS and SSP mode mode. > + > +config USB_CDNS3_HOST > +bool "Cadence USB3 host controller" > +depends on USB_XHCI_HCD > +help > + Say Y here to enable host controller functionality of the > + cadence driver. > + > + Host controller is compliance with XHCI so it will use compliant > + standard XHCI driver. > + > +config USB_CDNS3_PCI_WRAP > + tristate "Cadence USB3 support on PCIe-based platforms" > + depends on USB_PCI && ACPI > + default USB_CDNS3 > + help > + If you're using the USBSS Core IP with a PCIe, please say > + 'Y' or 'M' here. > + > + If you choose to build this driver as module it will > + be dynamically linked and module will be called cdns3-pci.ko > + > +endif g'day. -- ~Randy
Re: FYI: Userland breakage caused by udev bind commit
On Sun, Dec 23, 2018 at 05:49:54PM +0100, Marcus Meissner wrote:
> Hi,
>
> I am the maintainer of libmtp and libgphoto2
>
> Some months ago I was made aware of this bug:
> https://bugs.kde.org/show_bug.cgi?id=387454
>
> This was fallout identified to come from this kernel commit:
>
> commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65
> Author: Dmitry Torokhov
> Date: Wed Jul 19 17:24:30 2017 -0700
Fwiw, the addition of {un}bind events has caused issues for
systemd-udevd as well and is tracked here:
https://github.com/systemd/systemd/issues/7587
I haven't been aware of this until yesterday and it seems that so far
this hasn't been brought up on lkml until you did now.
>
> If distributions would be using libmtp and libgphoto2 udev rules
> that just triggered on "add" events, and not the new "bind" events,
> the missing "attribute tagging" of the "bind" events would confused the
> KDE Solid device detection and make the devices no longer detected.
>
> This did not affect distributions that rely on the newer "hwdb"
> device detection method.
>
> I have released fixed libmtp and libgphoto2 versions in November, so
> this is under control, but wanted to bring this up as a "kernel caused
> userland breakage".
>
> Ciao, Marcus
Re: [PATCH v2 03/11] vga-switcheroo: make PCI dependency explicit
On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
> On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
> > On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> > > This driver depends on the PCI infrastructure but the dependency has not
> > > been explicitly called out.
> > >
> > > Signed-off-by: Sinan Kaya
> > > Reviewed-by: Lukas Wunner
> >
> > This series doesn't have a cover letter so it's unclear to me through
> > which tree it's supposed to go in? Each patch through the individual
> > subsystem tree or all through the same tree? If the former I guess I
> > could push this to drm-misc...
>
> Feel free to apply individual patches independently. Let me know which
> one you applied so that I can drop them on the next rev.
I've realized only now that this patch fixes fallout of commit
5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
which is part of Rafael's acpi pull for v4.21.
Usually such fixes go through the same tree as the offending commit,
so I'd expect Raphael to pick up the whole series and forward it to
Linus in the second half of the merge window. I'm not sure if that's
how it'll play out though given the holidays.
Additionally, drm-misc is currently in a somewhat confusing state:
Normally fixes targeting v4.21 should have been applied to
drm-misc-next-fixes for the last 2 weeks, yet no new commits have
been applied to that branch since December 5, but plenty of stuff
that should have been applied (various fixes and a MAINTAINERS change)
went to drm-misc-next instead. So it looks like a lot of folks picked
the wrong branch and drm-misc-next is now a mix of v4.22 features and
v4.21 fixes. I think I should rather not add to this mess before a
drm-misc maintainer has had a chance to sort it out.
I'll be sure to keep an eye on this though. The fallout addressed by
the patch is mostly confined to randconfigs I think, so waiting a few
more days probably won't hurt much.
Thanks,
Lukas
Re: rfc: bool structure members (was Re: [PATCH V3] net/mlx4: Get rid of page operation after dma_alloc_coherent)
On Sun, Dec 23, 2018 at 06:42:20PM +0200, Gal Pressman wrote: > > -17) Don't re-invent the kernel macros > > +17) Using bool > > +-- > > + > > +The Linux kernel uses the C11 standard for the bool type. bool values can > > only C99, surely?
FYI: Userland breakage caused by udev bind commit
Hi, I am the maintainer of libmtp and libgphoto2 Some months ago I was made aware of this bug: https://bugs.kde.org/show_bug.cgi?id=387454 This was fallout identified to come from this kernel commit: commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 Author: Dmitry Torokhov Date: Wed Jul 19 17:24:30 2017 -0700 If distributions would be using libmtp and libgphoto2 udev rules that just triggered on "add" events, and not the new "bind" events, the missing "attribute tagging" of the "bind" events would confused the KDE Solid device detection and make the devices no longer detected. This did not affect distributions that rely on the newer "hwdb" device detection method. I have released fixed libmtp and libgphoto2 versions in November, so this is under control, but wanted to bring this up as a "kernel caused userland breakage". Ciao, Marcus
Re: rfc: bool structure members (was Re: [PATCH V3] net/mlx4: Get rid of page operation after dma_alloc_coherent)
On 22-Dec-18 01:52, Jason Gunthorpe wrote: > On Thu, Dec 20, 2018 at 09:12:43PM -0800, Joe Perches wrote: >> Care to submit a coding_style.rst patch or >> improve the one below this? > > I took yours and revised it a little bit. I spent some time looking at > assembly and decided to drop the performance note, the number of cases > that run into overhead seems pretty small and probably already > requires !! to be correct. There is also an equally unlikely gain, ie > 'if (a & b)' optimizes a tiny bit better for bool types. > > I also added a small intro on bool, as I know some people are > unfamiliar with C11 _Bool and might think bool is just '#define bool > u8' > > (for those added to the cc) I'm looking at cases, like the patch that > spawned this, where the struct has a single bool and no performance > considerations. As CH said, seeing that get converted to int due to > checkpatch is worse than having used bool. Using u8 won't make this > struct smaller or faster. > > Cheers, > Jason > > From c5e2c887f6326e1c4369876f39996417da5e90cc Mon Sep 17 00:00:00 2001 > From: Jason Gunthorpe > Date: Fri, 21 Dec 2018 16:29:22 -0700 > Subject: [PATCH] coding-style: Clarify the expectations around bool > > There has been some confusion since checkpatch started warning about bool > use in structures, and people have been avoiding using it. > > Many people feel there is still a legitimate place for bool in structures, > so provide some guidance on bool usage derived from the entire thread that > spawned the checkpatch warning. Since a "Using bool" section is added, perhaps it's worth documenting the bool usage as a function parameter [1]? [1] https://www.spinics.net/lists/linux-rdma/msg72336.html > > Link: > https://lkml.kernel.org/r/ca+55afwvzk1ofb9t2v014ptakfhtvan_zj2dojncy3x6e4u...@mail.gmail.com > Signed-off-by: Joe Perches > Signed-off-by: Jason Gunthorpe > --- > Documentation/process/coding-style.rst | 33 ++ > 1 file changed, 29 insertions(+), 4 deletions(-) > > diff --git a/Documentation/process/coding-style.rst > b/Documentation/process/coding-style.rst > index 4e7c0a1c427a9a..efdb1d32035fe1 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -918,7 +918,32 @@ result. Typical examples would be functions that return > pointers; they use > NULL or the ERR_PTR mechanism to report failure. > > > -17) Don't re-invent the kernel macros > +17) Using bool > +-- > + > +The Linux kernel uses the C11 standard for the bool type. bool values can > only > +evaluate to 0 or 1, and implicit or explicit conversion to bool automatically > +converts the value to true or false. When using bool types the !! > construction > +is not needed, which eliminates a class of bugs. > + > +When working with bool values the true and false labels should be used > instead > +of 0 and 1. > + > +bool function return types, arguments and stack variables are always fine to > +use whenever appropriate. Use of bool is encouraged to improve readability > and > +is often a better option than 'int' for storing boolean values. > + > +Do not use bool if cache line layout or size of the value matters, its size > +and alignment varies based on the compiled architecture. Structures that are > +optimized for alignment and size should not use bool. > + > +If a structure has many true/false values, consider consolidating them into a > +bitfield with 1 bit members, or using an appropriate fixed width type, such > as > +u8. > + > +Otherwise limited use of bool in structures does improve readability. > + > +18) Don't re-invent the kernel macros > - > > The header file include/linux/kernel.h contains a number of macros that > @@ -941,7 +966,7 @@ need them. Feel free to peruse that header file to see > what else is already > defined that you shouldn't reproduce in your code. > > > -18) Editor modelines and other cruft > +19) Editor modelines and other cruft > > > Some editors can interpret configuration information embedded in source > files, > @@ -975,7 +1000,7 @@ own custom mode, or may have some other magic method for > making indentation > work correctly. > > > -19) Inline assembly > +20) Inline assembly > --- > > In architecture-specific code, you may need to use inline assembly to > interface > @@ -1007,7 +1032,7 @@ the next instruction in the assembly output: >: /* outputs */ : /* inputs */ : /* clobbers */); > > > -20) Conditional Compilation > +21) Conditional Compilation > --- > > Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c >
Re: [PATCH 2/2] mfd: tps65218.c: Add input voltage options
* Lee Jones [181221 11:01]: > On Tue, 18 Dec 2018, Christian Hohnstaedt wrote: > > > These options apply to all regulators in this chip. > > > > strict-supply-voltage: > > Set STRICT flag in CONFIG1 > > under-voltage-limit: > > Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1 > > under-voltage-hysteresis: > > Select 200mV or 400mV UVLOHYS in CONFIG2 > > > > Signed-off-by: Christian Hohnstaedt > > --- > > drivers/mfd/tps65218.c | 46 ++ > > 1 file changed, 46 insertions(+) > > This needs a close review by Tony and any of the other OMAP guys. Adding Keerthy to Cc, he's probably the best person to review these changes. Regards, Tony
Re: [for-next][PATCH 4/5] tracing: Have the historgram use the result of str_has_prefix() for len of prefix
Hi Steve,
In the subject line, s/historgram/histogram...
On Sat, 2018-12-22 at 11:20 -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> As str_has_prefix() returns the length on match, we can use that for
> the
> updating of the string pointer instead of recalculating the prefix
> size.
>
> Cc: Tom Zanussi
> Signed-off-by: Steven Rostedt (VMware)
> ---
> kernel/trace/trace_events_hist.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
> index 0d878dcd1e4b..449d90cfa151 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -4342,12 +4342,13 @@ static int parse_actions(struct
> hist_trigger_data *hist_data)
> unsigned int i;
> int ret = 0;
> char *str;
> + int len;
>
> for (i = 0; i < hist_data->attrs->n_actions; i++) {
> str = hist_data->attrs->action_str[i];
>
> - if (str_has_prefix(str, "onmatch(")) {
> - char *action_str = str + sizeof("onmatch(")
> - 1;
> + if ((len = str_has_prefix(str, "onmatch("))) {
> + char *action_str = str + len;
>
> data = onmatch_parse(tr, action_str);
> if (IS_ERR(data)) {
> @@ -4355,8 +4356,8 @@ static int parse_actions(struct
> hist_trigger_data *hist_data)
> break;
> }
> data->fn = action_trace;
> - } else if (str_has_prefix(str, "onmax(")) {
> - char *action_str = str + sizeof("onmax(") -
> 1;
> + } else if ((len = str_has_prefix(str, "onmax("))) {
> + char *action_str = str + len;
>
> data = onmax_parse(action_str);
> if (IS_ERR(data)) {
Acked-by: Tom Zanussi
Re: [for-next][PATCH 2/5] tracing: Use str_has_prefix() helper for histogram code
On Sat, 2018-12-22 at 22:53 -0500, Steven Rostedt wrote:
> On Sat, 22 Dec 2018 12:03:41 -0600
> Tom Zanussi wrote:
>
> > Hi Steve,
> >
> > On Sat, 2018-12-22 at 13:01 -0500, Steven Rostedt wrote:
> > > On Sat, 22 Dec 2018 11:20:09 -0500
> > > Steven Rostedt wrote:
> > >
> > > > From: "Steven Rostedt (VMware)"
> > > >
> > > > The tracing histogram code contains a lot of instances of the
> > > > construct:
> > > >
> > > > strncmp(str, "const", sizeof("const") - 1)
> > > >
> > > > This can be prone to bugs due to typos or bad cut and paste.
> > > > Use
> > > > the
> > > > str_has_prefix() helper macro instead that removes the need for
> > > > having two
> > > > copies of the constant string.
> > > >
> > > > Cc: Tom Zanussi
> > >
> > > I have no idea why I copied your intel email. The linux.intel.com
> > > appears to be no longer active. I'm going to rebase to fix this
> > > email
> > > address.
> >
> > linux.intel.com is active, but there's no zanussi there, just
> > tom.zanussi ;-)
> >
> > So tom.zanu...@linux.intel.com should work fine.
>
> BTW, would you give me your ack-by?
>
Sure,
Acked-by: Tom Zanussi
Tom
> -- Steve
>
Re: [PATCH 11/18] mfd: tps65910: Make it explicitly non-modular
* Paul Gortmaker [181217 20:36]: > The Kconfig currently controlling compilation of this code is: > > drivers/mfd/Kconfig:config MFD_TPS65910 > drivers/mfd/Kconfig-bool "TI TPS65910 Power Management chip" > > ...meaning that it currently is not being built as a module by anyone. > > Lets remove the modular code that is essentially orphaned, so that > when reading the driver there is no doubt it is builtin-only. Acked-by: Tony Lindgren
[GIT PULL] Main MIPS pull for 4.21
Hi Linus, Here are the main MIPS changes for 4.21, summarized below. Please pull. Thanks, Paul The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a: Linux 4.20-rc1 (2018-11-04 15:37:52 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_4.21 for you to fetch changes up to adcc81f148d733b7e8e641300c5590a2cdc13bf3: MIPS: math-emu: Write-protect delay slot emulation pages (2018-12-20 10:00:01 -0800) Here's the main MIPS pull for Linux 4.21. Core architecture changes include: - Syscall tables & definitions for unistd.h are now generated by scripts, providing greater consistency with other architectures & making it easier to add new syscalls. - Support for building kernels with no floating point support, upon which any userland attempting to use floating point instructions will receive a SIGILL. Mostly useful to shrink the kernel & as preparation for nanoMIPS support which does not yet include FP. - MIPS SIMD Architecture (MSA) vector register context is now exposed by ptrace via a new NT_MIPS_MSA regset. - ASIDs are now stored as 64b values even for MIPS32 kernels, expanding the ASID version field sufficiently that we don't need to worry about overflow & avoiding rare issues with reused ASIDs that have been observed in the wild. - The branch delay slot "emulation" page is now mapped without write permission for the user, preventing its use as a nice location for attacks to execute malicious code from. - Support for ioremap_prot(), primarily to allow gdb or other ptrace users the ability to view their tracee's memory using the same cache coherency attribute. - Optimizations to more cpu_has_* macros, allowing more to be compile-time constant where possible. - Enable building the whole kernel with UBSAN instrumentation. - Enable building the kernel with link-time dead code & data elimination. Platform specific changes include: - The Boston board gains a workaround for DMA prefetching issues with the EG20T Platform Controller Hub that it uses. - Cleanups to Cavium Octeon code removing about 20k lines of redundant code, mostly unused or duplicate register definitions in headers. - defconfig updates for the DECstation machines, including new defconfigs for r4k & 64b machines. - Further work on Loongson 3 support. - DMA fixes for SiByte machines. Aaro Koskinen (30): MIPS: OCTEON: cvmx-l2c: make cvmx_l2c_spinlock static MIPS: OCTEON: setup: make internal functions and data static MIPS: OCTEON: setup: include asm/fw/fw.h MIPS: OCTEON: setup: include asm/prom.h MIPS: OCTEON: cvmx-helper: make __cvmx_helper_errata_fix_ipd_ptr_alignment static MIPS: OCTEON: delete unused loopback configuration functions MIPS: OCTEON: octeon-platform: make octeon_ids static MIPS: OCTEON: octeon-platform: fix typing MIPS: OCTEON: octeon-irq: make octeon_irq_ciu3_set_affinity() static MIPS: OCTEON: csrc-octeon: include linux/sched/clock.h MIPS: OCTEON: smp: make internal symbols static MIPS: OCTEON: cvmx-helper-util: delete cvmx_helper_dump_packet MIPS: OCTEON: cvmx-helper-util: make cvmx_helper_setup_red_queue static MIPS: OCTEON: make cvmx_bootmem_alloc_range static MIPS: OCTEON: cvmx-bootmem: delete unused functions MIPS: OCTEON: cvmx-bootmem: move code to avoid forward declarations MIPS: OCTEON: cvmx-bootmem: make more functions static MIPS: OCTEON: delete cvmx override functions MIPS: OCTEON: gmxx-defs.h: delete unused functions and macros MIPS: OCTEON: cvmx-gmxx-defs.h: delete unused unions MIPS: OCTEON: cvmx-gmxx-defs.h: delete unused union fields MIPS: OCTEON: cvmx-gmxx-defs.h: use default register value return when possible MIPS: OCTEON: cvmx-ciu2-defs.h: delete unused macros MIPS: OCTEON: cvmx-ciu2-defs.h: delete unused unions MIPS: OCTEON: enable all OCTEON drivers in defconfig MIPS: OCTEON: octeon-usb: use common gpio_bit definition MIPS: OCTEON: cvmx_pko_mem_debug8: use oldest forward compatible definition MIPS: OCTEON: cvmx_mio_fus_dat3: use oldest forward compatible definition MIPS: OCTEON: cvmx_gmxx_inf_mode: use oldest forward compatible definition MIPS: OCTEON: delete redundant register definitions Firoz Khan (7): mips: add __NR_syscalls along with __NR_Linux_syscalls mips: remove unused macros mips: rename scall64-64.S to scall64-n64.S mips: add +1 to __NR_syscalls in uapi header mips: remove syscall table entries mips: add system call table generation support mips: generate uapi header and system call table files Hassan Naveed (2): MIPS: Enable IOREMAP_PROT config option for
Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST
* Adam Ford [181222 20:36]: > As much as I'd like to see the ti-st kim stuff go, I am not able to > load the Bluetooth on the Torpedo board (wl1283). The hooks on a > different, wl18xx and 127x board work fine. I am not sure if there is > anything different about the wl1283, but I don't have any other boards > other than the Logic PD Torpedo kit. Do you have any wl1283 boards to > test? I'd like to see this BT timeout stuff resolved before we dump > the ti-st kim stuff, otherwise, I'll forever be porting drivers. :-( Sebastian and I both tested this with droid 4, which has wl1283. So it's probably some missing GPIO/regulator/pinconf stuff that the pdata-quirks.c does for you. Maybe try adding back also the pdata-quirks.c code and see if that helps? Regards, Tony
Re: [PATCH v5 0/7] mips: system call table generation support
Hi Firoz, On Sun, Dec 23, 2018 at 08:15:48AM -0800, Paul Burton wrote: > Hello, > > Firoz Khan wrote: > > The purpose of this patch series is, we can easily > > add/modify/delete system call table support by cha- > > nging entry in syscall.tbl file instead of manually > > changing many files. The other goal is to unify the > > system call table generation support implementation > > across all the architectures. >% > Series applied to mips-fixes. > > Thanks, > Paul > > [ This message was auto-generated; if you believe anything is incorrect > then please email paul.bur...@mips.com to report it. ] FYI this was actually applied to mips-next on the 14th & is part of the pull request I'm about to send for 4.21, but running my ack-email script is still a manual step & clearly still could be improved :) Thanks, Paul
[PATCH] target/iscsi: fix error msg typo when create lio_qr_cache failed
Signed-off-by: Leo Zhang
---
drivers/target/iscsi/iscsi_target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index c1d5a17..780a914 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -714,7 +714,7 @@ static int __init iscsi_target_init_module(void)
sizeof(struct iscsi_queue_req),
__alignof__(struct iscsi_queue_req), 0, NULL);
if (!lio_qr_cache) {
- pr_err("nable to kmem_cache_create() for"
+ pr_err("Unable to kmem_cache_create() for"
" lio_qr_cache\n");
goto bitmap_out;
}
--
1.8.3.1
Re: [PATCH] MAINTAINERS: Add a maintainer for MSCC MIPS SoCs
Hello, Alexandre Belloni wrote: > Microsemi has been bought by Microchip and Microchip is supporting those > SoCs. > > Signed-off-by: Alexandre Belloni > Acked-by: Woojung Huh Applied to mips-fixes. Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST
* Sebastian Reichel [181222 02:48]: > On Fri, Dec 21, 2018 at 10:02:05AM -0800, Tony Lindgren wrote: > > Hmm so looks like nothing to configure for the clocks or > > CPCAP_BIT_ST_L_TIMESLOT bits for cap for the EXT? So the > > wl12xx audio is wired directly to cpcap EXT then and not a > > TDM slot on the mcbsp huh? > > For FM radio it's directly wired to EXT with no DAI being required. > I think that EXT is only used by FM radio and not by bluetooth. BT > seems to use TDM. OK then it sounds like we just need a diff -u of the cpcap regs from Android with cpcaprw --all before and after using a bluetooth headset during a voice call to configure it for voice calls for the TDM. I think snd-soc-motmd just needs the voice output specified in the mixer in addition to the cpcap configuration. I don't think have any bluetooth audio gear though, maybe somebody using a headset can post the diff. Regards, Tony
Re: [PATCH v5 0/7] mips: system call table generation support
Hello, Firoz Khan wrote: > The purpose of this patch series is, we can easily > add/modify/delete system call table support by cha- > nging entry in syscall.tbl file instead of manually > changing many files. The other goal is to unify the > system call table generation support implementation > across all the architectures. > > The system call tables are in different format in > all architecture. It will be difficult to manually > add, modify or delete the system calls in the resp- > ective files manually. To make it easy by keeping a > script and which'll generate uapi header file and > syscall table file. > > syscall.tbl contains the list of available system > calls along with system call number and correspond- > ing entry point. Add a new system call in this arch- > itecture will be possible by adding new entry in > the syscall.tbl file. > > Adding a new table entry consisting of: > - System call number. > - ABI. > - System call name. > - Entry point name. > - Compat entry name, if required. > > ARM, s390 and x86 architecuture does exist the sim- > ilar support. I leverage their implementation to > come up with a generic solution. > > I have done the same support for work for alpha, > ia64, m68k, microblaze, parisc, powerpc, sh, sparc, > and xtensa. Below mentioned git repository contains > more details about the workflow. > > https://github.com/frzkhn/system_call_table_generator/ > > Finally, this is the ground work to solve the Y2038 > issue. We need to add two dozen of system calls to > solve Y2038 issue. So this patch series will help to > add new system calls easily by adding new entry in > the syscall.tbl. > > Changes since v4: > - _MIPS_SIM_ABIN64 (suppose to be _MIPS_SIM_NABI64) > macro rename back to _MIPS_SIM_ABI64 to avoid > toolchain issue. > > Changes since v3: > - rearranged the patches for '64' to 'n64' conver- > sion. > - moved the unistd_nr_*.h files to asm/unistd.h > - modified the *.sh files. > > Changes since v2: > - fixed __NR_syscalls assign issue. > > Changes since v1: > - optimized/updated the syscall table generation > scripts. > - fixed all mixed indentation issues in syscall.tbl. > - added "comments" in syscall_*.tbl. > - changed from generic-y to generated-y in Kbuild. > > Firoz Khan (7): > mips: add __NR_syscalls along with __NR_Linux_syscalls > mips: remove unused macros > mips: rename macros and files from '64' to 'n64' > mips: add +1 to __NR_syscalls in uapi header > mips: remove syscall table entries > mips: add system call table generation support > mips: generate uapi header and system call table files > > arch/mips/Makefile|3 + > arch/mips/include/asm/Kbuild |4 + > arch/mips/include/asm/unistd.h| 11 +- > arch/mips/include/uapi/asm/Kbuild |6 + > arch/mips/include/uapi/asm/unistd.h | 1074 + > arch/mips/kernel/Makefile |2 +- > arch/mips/kernel/ftrace.c |8 +- > arch/mips/kernel/scall32-o32.S| 391 +-- > arch/mips/kernel/scall64-64.S | 444 > arch/mips/kernel/scall64-n32.S| 341 + > arch/mips/kernel/scall64-n64.S| 117 > arch/mips/kernel/scall64-o32.S| 379 +- > arch/mips/kernel/syscalls/Makefile| 96 +++ > arch/mips/kernel/syscalls/syscall_n32.tbl | 343 + > arch/mips/kernel/syscalls/syscall_n64.tbl | 339 + > arch/mips/kernel/syscalls/syscall_o32.tbl | 382 ++ > arch/mips/kernel/syscalls/syscallhdr.sh | 37 + > arch/mips/kernel/syscalls/syscallnr.sh| 28 + > arch/mips/kernel/syscalls/syscalltbl.sh | 36 + > 19 files changed, 1427 insertions(+), 2614 deletions(-) > delete mode 100644 arch/mips/kernel/scall64-64.S > create mode 100644 arch/mips/kernel/scall64-n64.S > create mode 100644 arch/mips/kernel/syscalls/Makefile > create mode 100644 arch/mips/kernel/syscalls/syscall_n32.tbl > create mode 100644 arch/mips/kernel/syscalls/syscall_n64.tbl > create mode 100644 arch/mips/kernel/syscalls/syscall_o32.tbl > create mode 100644 arch/mips/kernel/syscalls/syscallhdr.sh > create mode 100644 arch/mips/kernel/syscalls/syscallnr.sh > create mode 100644 arch/mips/kernel/syscalls/syscalltbl.sh Series applied to mips-fixes. Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Yes: The linux devs can rescind their license grant.
Your new explanation was refuted 5 hours after it was published. --- Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outside counsel to analyze the fact pattern. (And even then all they
Re: [PATCH] MIPS: math-emu: Write-protect delay slot emulation pages
Hello,
Paul Burton wrote:
> Mapping the delay slot emulation page as both writeable & executable
> presents a security risk, in that if an exploit can write to & jump into
> the page then it can be used as an easy way to execute arbitrary code.
>
> Prevent this by mapping the page read-only for userland, and using
> access_process_vm() with the FOLL_FORCE flag to write to it from
> mips_dsemul().
>
> This will likely be less efficient due to copy_to_user_page() performing
> cache maintenance on a whole page, rather than a single line as in the
> previous use of flush_cache_sigtramp(). However this delay slot
> emulation code ought not to be running in any performance critical paths
> anyway so this isn't really a problem, and we can probably do better in
> copy_to_user_page() anyway in future.
>
> A major advantage of this approach is that the fix is small & simple to
> backport to stable kernels.
>
> Reported-by: Andy Lutomirski
> Signed-off-by: Paul Burton
> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot
> instructions")
> Cc: sta...@vger.kernel.org # v4.8+
Applied to mips-fixes.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur...@mips.com to report it. ]
The CoC regime is a License violation - Additional restrictive terms
Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is.
2 months and no response from Eben Moglen - Yes you can rescind your grant.
It has been 2 months. Eben Moglen has published no research. Because there is nothing more to say: The GPLv2, as used by linux, is a bare license. It can be rescinded at the will of the grantor. The regime that the FSF used, vis-a-vis the GPLv2, is essential: copyright transfers to a central repository entity that is sure not to rescind. Linus chose not to adopt this regime. He benefited by greatly increased developer contribution. The price for that windfall was and is the retention of their traditional property rights by the property holders. They can rescind at will. They made no promise nor utterance to the contrary that can be relied upon. They were paid no consideration. There was no meeting of the minds. Additionally the CoC regime itself is a license terms violation, being an additional restrictive term, as explained in the other analysis. (Similar to the GRSecurity license violation) On 2018-10-26 18:31, Eben Moglen wrote: On Friday, 26 October 2018, visionsofal...@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben
Reason for RedHat purchase 30 pct over market cap (and some thoughts on Bradly Kuhn's recent public denouncement of RMS)
Redhat has achieved "governance" over the Linux(TM), via systemd and the Code of Conduct. You, contributors, are now treated as employees. They are confident that you will not assert your property rights, since you attack those who do (See: Netfiter saga), and take it as an honour to sign documents pledging that you will not assert your property rights (prepared for you by your now-masters). They know that you are psychologically bound to behave as hirelings - servants, and not as property owners. Thus they can rest easy knowing the ground is, though made of sand, not in seeming danger of a tempest. Because of you. Because of your history of supplication. Your enuich-like nature. A nice example is Bradly Kuhn's recent blog posts 1) Excoriating RMS and 2) showing how he himself is submissive to a woman he hired. He's even angry that others still treat him with respect rather than transferring all the good will to the female figurehead everyone is supposed to now respect (for what reason? No, being an actual programmer is not required: sufficent is being a member of the "better" species that rules over the males under the anglo-american system that Bradly Kuhn and his kind uphold ) If I were them I would never donate another cent to the SFConservancy, and I would seek a claw-back of the funds that I did donate for improper use (yes this is possible under both California and New York law). Especially since they seem to have no in-house lawyers what-so-ever (so what is their purpose?). We are supposed to be proud that his mind is as innocent as his visage (perhaps why he had to hire outside counsel to give him an incorrect and abundantly couched opinion) [1] http://ebb.org/bkuhn/blog/2018/11/22/gnu-kind-communication-guidelines.html [2] http://ebb.org/bkuhn/blog/2018/06/21/everyday-sexism.html
Re: [PATCH 12/14] media: wl128x-radio: move from TI_ST to hci_ll driver
Hi Sebastian,
> This updates the wl128x-radio driver to be used with hci_ll
> instead of the deprecated TI_ST driver.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/bluetooth/hci_ll.c| 115 --
> drivers/media/radio/wl128x/Kconfig| 2 +-
> drivers/media/radio/wl128x/fmdrv.h| 1 +
> drivers/media/radio/wl128x/fmdrv_common.c | 101 ++-
> include/linux/ti_wilink_st.h | 2 +
> 5 files changed, 117 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 3e767f245ed5..6bcba57e9c9c 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -49,6 +49,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -62,6 +63,7 @@
> #define HCI_VS_UPDATE_UART_HCI_BAUDRATE 0xff36
>
> /* HCILL commands */
> +#define HCILL_FM_RADIO 0x08
> #define HCILL_GO_TO_SLEEP_IND 0x30
> #define HCILL_GO_TO_SLEEP_ACK 0x31
> #define HCILL_WAKE_UP_IND 0x32
> @@ -81,6 +83,10 @@ struct ll_device {
> struct gpio_desc *enable_gpio;
> struct clk *ext_clk;
> bdaddr_t bdaddr;
> +
> + struct platform_device *fmdev;
> + void (*fm_handler) (void *, struct sk_buff *);
> + void *fm_drvdata;
> };
>
> struct ll_struct {
> @@ -161,6 +167,35 @@ static int ll_flush(struct hci_uart *hu)
> return 0;
> }
>
> +static int ll_register_fm(struct ll_device *lldev)
> +{
> + struct device *dev = >serdev->dev;
> + int err;
> +
> + if (!of_device_is_compatible(dev->of_node, "ti,wl1281-st") &&
> + !of_device_is_compatible(dev->of_node, "ti,wl1283-st") &&
> + !of_device_is_compatible(dev->of_node, "ti,wl1285-st"))
> + return -ENODEV;
do we really want to hardcode this here? Isn't there some HCI vendor command or
some better DT description that we can use to decide when to register this
platform device.
> +
> + lldev->fmdev = platform_device_register_data(dev, "wl128x-fm",
> + PLATFORM_DEVID_AUTO, NULL, 0);
Fix the indentation please to following networking coding style.
> + err = PTR_ERR_OR_ZERO(lldev->fmdev);
> + if (err) {
> + dev_warn(dev, "cannot register FM radio subdevice: %d\n", err);
> + lldev->fmdev = NULL;
> + }
> +
> + return err;
> +}
> +
> +static void ll_unregister_fm(struct ll_device *lldev)
> +{
> + if (!lldev->fmdev)
> + return;
> + platform_device_unregister(lldev->fmdev);
> + lldev->fmdev = NULL;
> +}
> +
> /* Close protocol */
> static int ll_close(struct hci_uart *hu)
> {
> @@ -178,6 +213,8 @@ static int ll_close(struct hci_uart *hu)
> gpiod_set_value_cansleep(lldev->enable_gpio, 0);
>
> clk_disable_unprepare(lldev->ext_clk);
> +
> + ll_unregister_fm(lldev);
> }
>
> hu->priv = NULL;
> @@ -313,18 +350,11 @@ static void ll_device_woke_up(struct hci_uart *hu)
> hci_uart_tx_wakeup(hu);
> }
>
> -/* Enqueue frame for transmittion (padding, crc, etc) */
> -/* may be called from two simultaneous tasklets */
> -static int ll_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> +static int ll_enqueue_prefixed(struct hci_uart *hu, struct sk_buff *skb)
> {
> unsigned long flags = 0;
> struct ll_struct *ll = hu->priv;
>
> - BT_DBG("hu %p skb %p", hu, skb);
> -
> - /* Prepend skb with frame type */
> - memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
> -
> /* lock hcill state */
> spin_lock_irqsave(>hcill_lock, flags);
>
> @@ -361,6 +391,18 @@ static int ll_enqueue(struct hci_uart *hu, struct
> sk_buff *skb)
> return 0;
> }
>
> +/* Enqueue frame for transmittion (padding, crc, etc) */
> +/* may be called from two simultaneous tasklets */
> +static int ll_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> +{
> + BT_DBG("hu %p skb %p", hu, skb);
> +
> + /* Prepend skb with frame type */
> + memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
> +
> + return ll_enqueue_prefixed(hu, skb);
> +}
> +
> static int ll_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
> {
> struct hci_uart *hu = hci_get_drvdata(hdev);
> @@ -390,6 +432,32 @@ static int ll_recv_frame(struct hci_dev *hdev, struct
> sk_buff *skb)
> return 0;
> }
>
> +static int ll_recv_radio(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + struct hci_uart *hu = hci_get_drvdata(hdev);
> + struct serdev_device *serdev = hu->serdev;
> + struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> +
> + if (!lldev->fm_handler) {
> + kfree_skb(skb);
> + return -EINVAL;
> + }
> +
> + /* Prepend skb with frame type */
> + memcpy(skb_push(skb, 1), _skb_pkt_type(skb), 1);
> +
> + lldev->fm_handler(lldev->fm_drvdata, skb);
So I have no idea why we bother adding the frame type here. What is the
purpose. I think this is useless and we
Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver
* Pavel Machek [181223 11:11]: > I added some printks to motmdm_probe, and they don't appear to be > called. I wonder if I'm missing something else in the config? I do > have serial > > root@devuan:/my/ko# ls -al /dev/ttyS0 > crw-rw 1 root dialout 4, 64 Dec 23 11:52 /dev/ttyS0 > > but not gsm multiplex: > > root@devuan:/my/ko# ls -al /dev/gsm* > ls: cannot access '/dev/gsm*': No such file or directory Hmm with serdev you should not get /dev/ttyS0, so maybe you're missing: CONFIG_SERIAL_DEV_BUS=y CONFIG_SERIAL_DEV_CTRL_TTYPORT=y Probably the Kconfig dependency should be for SERIAL_DEV_CTRL_TTYPORT instead of SERIAL_DEV_BUS in these patches if that helps. Or else you're missing the serdev related dts changes? Regards, Tony
Re: [PATCH] scsi: convert to DEFINE_SHOW_ATTRIBUTE
ping..
Re: [PATCH] dma-buf: Change to use DEFINE_SHOW_ATTRIBUTE macro
ping..
[RESNED] mfd: convert to DEFINE_SHOW_ATTRIBUTE
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
Acked-for-MFD-by: Lee Jones
Acked-by: Linus Walleij
---
drivers/mfd/ab3100-core.c | 15 ++-
drivers/mfd/ab3100-otp.c | 16 +++-
drivers/mfd/tps65010.c| 14 ++
3 files changed, 7 insertions(+), 38 deletions(-)
diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index 099635bed188..3fe448a29389 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -451,7 +451,7 @@ static irqreturn_t ab3100_irq_handler(int irq, void *data)
/*
* Some debugfs entries only exposed if we're using debug
*/
-static int ab3100_registers_print(struct seq_file *s, void *p)
+static int ab3100_registers_show(struct seq_file *s, void *p)
{
struct ab3100 *ab3100 = s->private;
u8 value;
@@ -466,18 +466,7 @@ static int ab3100_registers_print(struct seq_file *s, void
*p)
return 0;
}
-static int ab3100_registers_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ab3100_registers_print, inode->i_private);
-}
-
-static const struct file_operations ab3100_registers_fops = {
- .open = ab3100_registers_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_SHOW_ATTRIBUTE(ab3100_registers);
struct ab3100_get_set_reg_priv {
struct ab3100 *ab3100;
diff --git a/drivers/mfd/ab3100-otp.c b/drivers/mfd/ab3100-otp.c
index 55b207a4b336..24873e1ae865 100644
--- a/drivers/mfd/ab3100-otp.c
+++ b/drivers/mfd/ab3100-otp.c
@@ -96,7 +96,7 @@ static int __init ab3100_otp_read(struct ab3100_otp *otp)
* the contents of the OTP.
*/
#ifdef CONFIG_DEBUG_FS
-static int ab3100_show_otp(struct seq_file *s, void *v)
+static int ab3100_otp_show(struct seq_file *s, void *v)
{
struct ab3100_otp *otp = s->private;
@@ -110,24 +110,14 @@ static int ab3100_show_otp(struct seq_file *s, void *v)
return 0;
}
-static int ab3100_otp_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ab3100_show_otp, inode->i_private);
-}
-
-static const struct file_operations ab3100_otp_operations = {
- .open = ab3100_otp_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ab3100_otp);
static int __init ab3100_otp_init_debugfs(struct device *dev,
struct ab3100_otp *otp)
{
otp->debugfs = debugfs_create_file("ab3100_otp", S_IFREG | S_IRUGO,
NULL, otp,
- _otp_operations);
+ _otp_fops);
if (!otp->debugfs) {
dev_err(dev, "AB3100 debugfs OTP file registration failed!\n");
return -ENOENT;
diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
index 2ab67386b4ef..4202b5c40f18 100644
--- a/drivers/mfd/tps65010.c
+++ b/drivers/mfd/tps65010.c
@@ -192,7 +192,7 @@ static inline void show_chgconfig(int por, const char
*label, u8 chgconfig) { }
#ifdef CONFIG_DEBUG_FS
-static int dbg_show(struct seq_file *s, void *_)
+static int debug_show(struct seq_file *s, void *_)
{
struct tps65010 *tps = s->private;
u8 value, v2;
@@ -296,17 +296,7 @@ static int dbg_show(struct seq_file *s, void *_)
return 0;
}
-static int dbg_tps_open(struct inode *inode, struct file *file)
-{
- return single_open(file, dbg_show, inode->i_private);
-}
-
-static const struct file_operations debug_fops = {
- .open = dbg_tps_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(debug);
#defineDEBUG_FOPS _fops
--
2.17.0
[PATCH] bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
This happened when I tried to boot normal Fedora 29 system with latest
available kernel (from fedora rawhide, plus some unrelated custom
patches):
BUG: unable to handle kernel NULL pointer dereference at
PGD 0 P4D 0
Oops: 0010 [#1] SMP PTI
CPU: 6 PID: 1422 Comm: libvirtd Tainted: G I
4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
RIP: 0010: (null)
Code: Bad RIP value.
RSP: 0018:a47ccdc9fbe0 EFLAGS: 00010246
RAX: RBX: 03e8 RCX: a47ccdc9fbf8
RDX: a47ccdc9fc00 RSI: 97d9ee7b01f8 RDI: 97d9f0150b80
RBP: 97d9f0150b80 R08: R09:
R10: R11: R12: 0003
R13: 97d9ef1e53e8 R14: 0009 R15: 97d9f0ac6730
FS: 7f4d224ef700() GS:97d9fa20()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: ffd6 CR3: 0011ece52006 CR4: 000206e0
Call Trace:
? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
? bnx2x_set_features+0x79/0xa0 [bnx2x]
? __netdev_update_features+0x244/0x9e0
? netlink_broadcast_filtered+0x136/0x4b0
? netdev_update_features+0x22/0x60
? dev_disable_lro+0x1c/0xe0
? devinet_sysctl_forward+0x1c6/0x211
? proc_sys_call_handler+0xab/0x100
? __vfs_write+0x36/0x1a0
? rcu_read_lock_sched_held+0x79/0x80
? rcu_sync_lockdep_assert+0x2e/0x60
? __sb_start_write+0x14c/0x1b0
? vfs_write+0x159/0x1c0
? vfs_write+0xba/0x1c0
? ksys_write+0x52/0xc0
? do_syscall_64+0x60/0x1f0
? entry_SYSCALL_64_after_hwframe+0x49/0xbe
After some investigation I figured out that recently added cleanup code
tries to call VLAN filtering de-initialization function which exist only
for newer hardware. Corresponding function pointer is not
initialized (== 0) for older hardware, namely these chips:
#define CHIP_NUM_57710 0x164e
#define CHIP_NUM_57711 0x164f
#define CHIP_NUM_57711E 0x1650
And I have one of those in my test system:
02:00.0 Ethernet controller [0200]: Broadcom Inc. and subsidiaries
NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650]
02:00.1 Ethernet controller [0200]: Broadcom Inc. and subsidiaries
NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650]
Function bnx2x_init_vlan_mac_fp_objs() from
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to
initialize relevant pointers in bnx2x_sp_objs.vlan_obj or not.
This regression was introduced after v4.20-rc7.
Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload
sequence.")
Signed-off-by: Ivan Mironov
---
.../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 22 +--
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index b164f705709d..0e37c2484ac2 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -8504,15 +8504,23 @@ int bnx2x_set_vlan_one(struct bnx2x *bp, u16 vlan,
static int bnx2x_del_all_vlans(struct bnx2x *bp)
{
struct bnx2x_vlan_mac_obj *vlan_obj = >sp_objs[0].vlan_obj;
- unsigned long ramrod_flags = 0, vlan_flags = 0;
struct bnx2x_vlan_entry *vlan;
- int rc;
- __set_bit(RAMROD_COMP_WAIT, _flags);
- __set_bit(BNX2X_VLAN, _flags);
- rc = vlan_obj->delete_all(bp, vlan_obj, _flags, _flags);
- if (rc)
- return rc;
+ /* The whole *vlan_obj structure may be not initialized if VLAN
+* filtering offload is not supported by hardware. Currently this is
+* true for all hardware covered by CHIP_IS_E1x().
+*/
+ if (vlan_obj->delete_all) {
+ unsigned long ramrod_flags = 0, vlan_flags = 0;
+ int rc;
+
+ __set_bit(RAMROD_COMP_WAIT, _flags);
+ __set_bit(BNX2X_VLAN, _flags);
+ rc = vlan_obj->delete_all(bp, vlan_obj, _flags,
+ _flags);
+ if (rc)
+ return rc;
+ }
/* Mark that hw forgot all entries */
list_for_each_entry(vlan, >vlan_reg, link)
--
2.20.1
[PATCH] x86/trace: set TRACE_INCLUDE_PATH instead of include path
Set TRACE_INCLUDE_PATH correctly for exceptions.h and irq_vectors.h This is consistent with fpu.h, hyperv.h, mpx.h in the same directory. The ugly include paths will go away. Signed-off-by: Masahiro Yamada --- arch/x86/include/asm/trace/exceptions.h | 2 +- arch/x86/include/asm/trace/irq_vectors.h | 2 +- arch/x86/kernel/Makefile | 2 -- arch/x86/mm/Makefile | 2 -- 4 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/trace/exceptions.h b/arch/x86/include/asm/trace/exceptions.h index 69615e3..3d1f138 100644 --- a/arch/x86/include/asm/trace/exceptions.h +++ b/arch/x86/include/asm/trace/exceptions.h @@ -45,7 +45,7 @@ DEFINE_PAGE_FAULT_EVENT(page_fault_user); DEFINE_PAGE_FAULT_EVENT(page_fault_kernel); #undef TRACE_INCLUDE_PATH -#define TRACE_INCLUDE_PATH . +#define TRACE_INCLUDE_PATH asm/trace/ #define TRACE_INCLUDE_FILE exceptions #endif /* _TRACE_PAGE_FAULT_H */ diff --git a/arch/x86/include/asm/trace/irq_vectors.h b/arch/x86/include/asm/trace/irq_vectors.h index 0af81b5..e38a76e 100644 --- a/arch/x86/include/asm/trace/irq_vectors.h +++ b/arch/x86/include/asm/trace/irq_vectors.h @@ -389,7 +389,7 @@ TRACE_EVENT(vector_free_moved, #endif /* CONFIG_X86_LOCAL_APIC */ #undef TRACE_INCLUDE_PATH -#define TRACE_INCLUDE_PATH . +#define TRACE_INCLUDE_PATH asm/trace/ #define TRACE_INCLUDE_FILE irq_vectors #endif /* _TRACE_IRQ_VECTORS_H */ diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index da0b6bc..e581734 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -42,8 +42,6 @@ endif # non-deterministic coverage. KCOV_INSTRUMENT:= n -CFLAGS_irq.o := -I$(src)/../include/asm/trace - obj-y := process_$(BITS).o signal.o obj-$(CONFIG_COMPAT) += signal_compat.o obj-y += traps.o idt.o irq.o irq_$(BITS).o dumpstack_$(BITS).o diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 4b101dd..6d474d9 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -21,8 +21,6 @@ CFLAGS_physaddr.o := $(nostackp) CFLAGS_setup_nx.o := $(nostackp) CFLAGS_mem_encrypt_identity.o := $(nostackp) -CFLAGS_fault.o := -I$(src)/../include/asm/trace - obj-$(CONFIG_X86_PAT) += pat_rbtree.o obj-$(CONFIG_X86_32) += pgtable_32.o iomap_32.o -- 2.7.4
[PATCH v2 3/5] usb:common Patch simplify usb_decode_set_clear_feature function.
Patch adds usb_decode_test_mode and usb_decode_device_feature functions,
which allow to make more readable and simplify the
usb_decode_set_clear_feature function.
Signed-off-by: Pawel Laszczak
---
drivers/usb/common/debug.c | 83 ++
1 file changed, 40 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/common/debug.c b/drivers/usb/common/debug.c
index 374fb9e94f37..77e565a38f29 100644
--- a/drivers/usb/common/debug.c
+++ b/drivers/usb/common/debug.c
@@ -29,6 +29,44 @@ static void usb_decode_get_status(__u8 bRequestType, __u16
wIndex,
}
}
+static const char *usb_decode_device_feature(u16 wValue)
+{
+ switch (wValue) {
+ case USB_DEVICE_SELF_POWERED:
+ return "Self Powered";
+ case USB_DEVICE_REMOTE_WAKEUP:
+ return "Remote Wakeup";
+ case USB_DEVICE_TEST_MODE:
+ return "Test Mode";
+ case USB_DEVICE_U1_ENABLE:
+ return "U1 Enable";
+ case USB_DEVICE_U2_ENABLE:
+ return "U2 Enable";
+ case USB_DEVICE_LTM_ENABLE:
+ return "LTM Enable";
+ default:
+ return "UNKNOWN";
+ }
+}
+
+static const char *usb_decode_test_mode(u16 wIndex)
+{
+ switch (wIndex) {
+ case TEST_J:
+ return ": TEST_J";
+ case TEST_K:
+ return ": TEST_K";
+ case TEST_SE0_NAK:
+ return ": TEST_SE0_NAK";
+ case TEST_PACKET:
+ return ": TEST_PACKET";
+ case TEST_FORCE_EN:
+ return ": TEST_FORCE_EN";
+ default:
+ return ": UNKNOWN";
+ }
+}
+
static void usb_decode_set_clear_feature(__u8 bRequestType,
__u8 bRequest, __u16 wValue,
__u16 wIndex, char *str)
@@ -37,50 +75,9 @@ static void usb_decode_set_clear_feature(__u8 bRequestType,
case USB_RECIP_DEVICE:
sprintf(str, "%s Device Feature(%s%s)",
bRequest == USB_REQ_CLEAR_FEATURE ? "Clear" : "Set",
- ({char *s;
- switch (wValue) {
- case USB_DEVICE_SELF_POWERED:
- s = "Self Powered";
- break;
- case USB_DEVICE_REMOTE_WAKEUP:
- s = "Remote Wakeup";
- break;
- case USB_DEVICE_TEST_MODE:
- s = "Test Mode";
- break;
- case USB_DEVICE_U1_ENABLE:
- s = "U1 Enable";
- break;
- case USB_DEVICE_U2_ENABLE:
- s = "U2 Enable";
- break;
- case USB_DEVICE_LTM_ENABLE:
- s = "LTM Enable";
- break;
- default:
- s = "UNKNOWN";
- } s; }),
+ usb_decode_device_feature(wValue),
wValue == USB_DEVICE_TEST_MODE ?
- ({ char *s;
- switch (wIndex) {
- case TEST_J:
- s = ": TEST_J";
- break;
- case TEST_K:
- s = ": TEST_K";
- break;
- case TEST_SE0_NAK:
- s = ": TEST_SE0_NAK";
- break;
- case TEST_PACKET:
- s = ": TEST_PACKET";
- break;
- case TEST_FORCE_EN:
- s = ": TEST_FORCE_EN";
- break;
- default:
- s = ": UNKNOWN";
- } s; }) : "");
+ usb_decode_test_mode(wIndex) : "");
break;
case USB_RECIP_INTERFACE:
sprintf(str, "%s Interface Feature(%s)",
--
2.17.1
[PATCH v2 4/5] usb:common Simplify usb_decode_get_set_descriptor function.
Patch moves switch responsible for decoding descriptor type
outside snprintf. It's little improves code readability.
Signed-off-by: Pawel Laszczak
---
drivers/usb/common/debug.c | 111 +++--
1 file changed, 57 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/common/debug.c b/drivers/usb/common/debug.c
index 77e565a38f29..c15fa066339c 100644
--- a/drivers/usb/common/debug.c
+++ b/drivers/usb/common/debug.c
@@ -104,62 +104,65 @@ static void usb_decode_get_set_descriptor(__u8
bRequestType, __u8 bRequest,
__u16 wValue, __u16 wIndex,
__u16 wLength, char *str)
{
+ char *s;
+
+ switch (wValue >> 8) {
+ case USB_DT_DEVICE:
+ s = "Device";
+ break;
+ case USB_DT_CONFIG:
+ s = "Configuration";
+ break;
+ case USB_DT_STRING:
+ s = "String";
+ break;
+ case USB_DT_INTERFACE:
+ s = "Interface";
+ break;
+ case USB_DT_ENDPOINT:
+ s = "Endpoint";
+ break;
+ case USB_DT_DEVICE_QUALIFIER:
+ s = "Device Qualifier";
+ break;
+ case USB_DT_OTHER_SPEED_CONFIG:
+ s = "Other Speed Config";
+ break;
+ case USB_DT_INTERFACE_POWER:
+ s = "Interface Power";
+ break;
+ case USB_DT_OTG:
+ s = "OTG";
+ break;
+ case USB_DT_DEBUG:
+ s = "Debug";
+ break;
+ case USB_DT_INTERFACE_ASSOCIATION:
+ s = "Interface Association";
+ break;
+ case USB_DT_BOS:
+ s = "BOS";
+ break;
+ case USB_DT_DEVICE_CAPABILITY:
+ s = "Device Capability";
+ break;
+ case USB_DT_PIPE_USAGE:
+ s = "Pipe Usage";
+ break;
+ case USB_DT_SS_ENDPOINT_COMP:
+ s = "SS Endpoint Companion";
+ break;
+ case USB_DT_SSP_ISOC_ENDPOINT_COMP:
+ s = "SSP Isochronous Endpoint Companion";
+ break;
+ default:
+ s = "UNKNOWN";
+ break;
+ }
+
sprintf(str, "%s %s Descriptor(Index = %d, Length = %d)",
bRequest == USB_REQ_GET_DESCRIPTOR ? "Get" : "Set",
- ({ char *s;
- switch (wValue >> 8) {
- case USB_DT_DEVICE:
- s = "Device";
- break;
- case USB_DT_CONFIG:
- s = "Configuration";
- break;
- case USB_DT_STRING:
- s = "String";
- break;
- case USB_DT_INTERFACE:
- s = "Interface";
- break;
- case USB_DT_ENDPOINT:
- s = "Endpoint";
- break;
- case USB_DT_DEVICE_QUALIFIER:
- s = "Device Qualifier";
- break;
- case USB_DT_OTHER_SPEED_CONFIG:
- s = "Other Speed Config";
- break;
- case USB_DT_INTERFACE_POWER:
- s = "Interface Power";
- break;
- case USB_DT_OTG:
- s = "OTG";
- break;
- case USB_DT_DEBUG:
- s = "Debug";
- break;
- case USB_DT_INTERFACE_ASSOCIATION:
- s = "Interface Association";
- break;
- case USB_DT_BOS:
- s = "BOS";
- break;
- case USB_DT_DEVICE_CAPABILITY:
- s = "Device Capability";
- break;
- case USB_DT_PIPE_USAGE:
- s = "Pipe Usage";
- break;
- case USB_DT_SS_ENDPOINT_COMP:
- s = "SS Endpoint Companion";
- break;
- case USB_DT_SSP_ISOC_ENDPOINT_COMP:
- s = "SSP Isochronous Endpoint Companion";
- break;
- default:
- s = "UNKNOWN";
- break;
- } s; }), wValue & 0xff, wLength);
+ s, wValue & 0xff,
[PATCH v2 2/5] usb:common Separated decoding functions from dwc3 driver.
Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
to driver/usb/common/debug.c file. These moved functions include:
dwc3_decode_get_status
dwc3_decode_set_clear_feature
dwc3_decode_set_address
dwc3_decode_get_set_descriptor
dwc3_decode_get_configuration
dwc3_decode_set_configuration
dwc3_decode_get_intf
dwc3_decode_set_intf
dwc3_decode_synch_frame
dwc3_decode_set_sel
dwc3_decode_set_isoch_delay
dwc3_decode_ctrl
These functions are used also in inroduced cdns3 driver.
All functions prefixes were changed from dwc3 to usb.
Also, function's parameters has been extended according to the name
of fields in standard SETUP packet.
Additionally, patch adds usb_decode_ctrl function to
include/linux/usb/ch9.h file.
mend
Signed-off-by: Pawel Laszczak
---
drivers/usb/common/Makefile | 2 +-
drivers/usb/common/debug.c | 265
drivers/usb/dwc3/debug.h| 243 -
drivers/usb/dwc3/trace.h| 2 +-
include/linux/usb/ch9.h | 19 +++
5 files changed, 286 insertions(+), 245 deletions(-)
create mode 100644 drivers/usb/common/debug.c
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index fb4d5ef4165c..3d3d2962ea4b 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,7 +4,7 @@
#
obj-$(CONFIG_USB_COMMON) += usb-common.o
-usb-common-y += common.o
+usb-common-y += common.o debug.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
diff --git a/drivers/usb/common/debug.c b/drivers/usb/common/debug.c
new file mode 100644
index ..374fb9e94f37
--- /dev/null
+++ b/drivers/usb/common/debug.c
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Common USB debugging functions
+ *
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors: Felipe Balbi ,
+ * Sebastian Andrzej Siewior
+ */
+
+#ifndef __LINUX_USB_COMMON_DEBUG
+#define __LINUX_USB_COMMON_DEBUG
+
+#include
+
+static void usb_decode_get_status(__u8 bRequestType, __u16 wIndex,
+ __u16 wLength, char *str)
+{
+ switch (bRequestType & USB_RECIP_MASK) {
+ case USB_RECIP_INTERFACE:
+ sprintf(str, "Get Interface Status(Intf = %d, Length = %d)",
+ wIndex, wLength);
+ break;
+ case USB_RECIP_ENDPOINT:
+ sprintf(str, "Get Endpoint Status(ep%d%s)",
+ wIndex & ~USB_DIR_IN,
+ wIndex & USB_DIR_IN ? "in" : "out");
+ break;
+ }
+}
+
+static void usb_decode_set_clear_feature(__u8 bRequestType,
+__u8 bRequest, __u16 wValue,
+__u16 wIndex, char *str)
+{
+ switch (bRequestType & USB_RECIP_MASK) {
+ case USB_RECIP_DEVICE:
+ sprintf(str, "%s Device Feature(%s%s)",
+ bRequest == USB_REQ_CLEAR_FEATURE ? "Clear" : "Set",
+ ({char *s;
+ switch (wValue) {
+ case USB_DEVICE_SELF_POWERED:
+ s = "Self Powered";
+ break;
+ case USB_DEVICE_REMOTE_WAKEUP:
+ s = "Remote Wakeup";
+ break;
+ case USB_DEVICE_TEST_MODE:
+ s = "Test Mode";
+ break;
+ case USB_DEVICE_U1_ENABLE:
+ s = "U1 Enable";
+ break;
+ case USB_DEVICE_U2_ENABLE:
+ s = "U2 Enable";
+ break;
+ case USB_DEVICE_LTM_ENABLE:
+ s = "LTM Enable";
+ break;
+ default:
+ s = "UNKNOWN";
+ } s; }),
+ wValue == USB_DEVICE_TEST_MODE ?
+ ({ char *s;
+ switch (wIndex) {
+ case TEST_J:
+ s = ": TEST_J";
+ break;
+ case TEST_K:
+ s = ": TEST_K";
+ break;
+ case TEST_SE0_NAK:
+ s = ": TEST_SE0_NAK";
+ break;
+ case
[PATCH v2 0/5] Introduced new Cadence USBSS DRD Driver.
This patch set introduce new Cadence USBSS DRD driver to linux kernel. The Cadence USBSS DRD Driver s a highly configurable IP Core which can be instantiated as Dual-Role Device (DRD), Peripheral Only and Host Only (XHCI) configurations. The current driver has been validated with FPGA burned. We have support for PCIe bus, which is used on FPGA prototyping. The host site of USBSS controller is compliance with XHCI specification, so it works with standard XHCI linux driver. Changes since v1: - Removed not implemented Susped/Resume functions. - Fixed some issues in debugging related functions. - Added trace_cdns3_request_handled marker. - Added support for Isochronouse transfer. - Added some additional descriptions. - Fixed compilation error in cdns3_gadget_ep_disable. - Added detection of device controller version at runtime. - Upgraded dt-binding documentation. - Deleted ENOSYS from phy initialization section. It should be also removed from generic PHY driver. - added ep0_stage flag used during enumeration process. - Fixed issue with TEST MODE. - Added one common function for finish control transfer. - Separated some decoding function from dwc3 driver to common library file, and removed equivalents function from debug.h file as suggested by Felipe. - replaced function name cdns3_gadget_unconfig with cdns3_hw_reset_eps_config. - Improved algorithm fixing hardware issue related to blocking endpoints. This issue is related to on-chip shared FIFO buffers for OUT packets. Problem was reported by Peter Chan. - Changed organization of endpoint array in cdns3_device object. - added ep0 to common eps array - removed cdns3_free_trb_pool and cdns3_ep_addr_to_bit_pos macros. - removed ep0_trb_dma, ep0_trb fields from cdns3_device. - Removed ep0_request and ep_nums fields from cdns3_device. - Other minor changes according with Felipe suggestion. --- Pawel Laszczak (5): dt-bindings: add binding for USBSS-DRD controller. usb:common Separated decoding functions from dwc3 driver. usb:common Patch simplify usb_decode_set_clear_feature function. usb:common Simplify usb_decode_get_set_descriptor function. usb:cdns3 Add Cadence USB3 DRD Driver .../devicetree/bindings/usb/cdns3-usb.txt | 30 + drivers/usb/Kconfig |2 + drivers/usb/Makefile |2 + drivers/usb/cdns3/Kconfig | 44 + drivers/usb/cdns3/Makefile| 16 + drivers/usb/cdns3/cdns3-pci-wrap.c| 157 ++ drivers/usb/cdns3/core.c | 406 drivers/usb/cdns3/core.h | 116 + drivers/usb/cdns3/debug.h | 166 ++ drivers/usb/cdns3/debugfs.c | 168 ++ drivers/usb/cdns3/drd.c | 350 +++ drivers/usb/cdns3/drd.h | 162 ++ drivers/usb/cdns3/ep0.c | 896 +++ drivers/usb/cdns3/gadget-export.h | 28 + drivers/usb/cdns3/gadget.c| 2102 + drivers/usb/cdns3/gadget.h| 1206 ++ drivers/usb/cdns3/host-export.h | 28 + drivers/usb/cdns3/host.c | 72 + drivers/usb/cdns3/trace.c | 11 + drivers/usb/cdns3/trace.h | 389 +++ drivers/usb/common/Makefile |2 +- drivers/usb/common/debug.c| 265 +++ drivers/usb/dwc3/debug.h | 243 -- drivers/usb/dwc3/trace.h |2 +- include/linux/usb/ch9.h | 19 + 25 files changed, 6637 insertions(+), 245 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/cdns3-usb.txt create mode 100644 drivers/usb/cdns3/Kconfig create mode 100644 drivers/usb/cdns3/Makefile create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c create mode 100644 drivers/usb/cdns3/core.c create mode 100644 drivers/usb/cdns3/core.h create mode 100644 drivers/usb/cdns3/debug.h create mode 100644 drivers/usb/cdns3/debugfs.c create mode 100644 drivers/usb/cdns3/drd.c create mode 100644 drivers/usb/cdns3/drd.h create mode 100644 drivers/usb/cdns3/ep0.c create mode 100644 drivers/usb/cdns3/gadget-export.h create mode 100644 drivers/usb/cdns3/gadget.c create mode 100644 drivers/usb/cdns3/gadget.h create mode 100644 drivers/usb/cdns3/host-export.h create mode 100644 drivers/usb/cdns3/host.c create mode 100644 drivers/usb/cdns3/trace.c create mode 100644 drivers/usb/cdns3/trace.h create mode 100644 drivers/usb/common/debug.c -- 2.17.1
[PATCH v2 1/5] dt-bindings: add binding for USBSS-DRD controller.
This patch aim at documenting USB related dt-bindings for the
Cadence USBSS-DRD controller.
Signed-off-by: Pawel Laszczak
---
.../devicetree/bindings/usb/cdns3-usb.txt | 30 +++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/cdns3-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/cdns3-usb.txt
b/Documentation/devicetree/bindings/usb/cdns3-usb.txt
new file mode 100644
index ..cf93bd0de5cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cdns3-usb.txt
@@ -0,0 +1,30 @@
+Binding for the Cadence USBSS-DRD controller
+
+Required properties:
+ - reg: Physical base address and size of the controller's register areas.
+Controller has 3 different regions:
+region 1 - HOST registers area
+region 2 - DEVICE registers area
+region 3 - OTG/DRD registers area
+ - compatible: Should contain: "cdns,usb3-1.0.0" or "cdns,usb3-1.0.1"
+ - interrupts: Interrupt specifier. Refer to interrupt bindings.
+ Driver supports only single interrupt line.
+This single interrupt is shared between Device,
+ host and OTG/DRD part of driver.
+
+Optional properties:
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+ "full-speed"; refer to usb/generic.txt
+ - dr_mode: Should be one of "host", "peripheral" or "otg".
+ - phys: reference to the USB PHY
+ - phy-names: name of the USB PHY, should be "cdns3,usbphy"
+
+
+Example:
+ usb@f300 {
+ compatible = "cdns,usb3";
+ interrupts = ;
+ reg = <0xf300 0x1 /* memory area for HOST
registers */
+ 0xf301 0x1 /* memory area for DEVICE
registers */
+ 0xf302 0x1>;/* memory area for OTG/DRD
registers */
+ };
--
2.17.1
Re: [PATCH] RISC-V: Make BSS section as the last section in vmlinux.lds.S
On Fri, Dec 21, 2018 at 2:10 AM Palmer Dabbelt wrote: > > On Mon, 17 Dec 2018 01:36:45 PST (-0800), a...@brainfault.org wrote: > > On Mon, Nov 26, 2018 at 11:42 AM Anup Patel wrote: > >> > >> The objcopy only emits loadable sections when creating flat kernel > >> Image. To have minimal possible size of flat kernel Image, we should > >> have all non-loadable sections after loadable sections. > >> > >> Currently, execption table section (loadable section) is after BSS > >> section (non-loadable section) in the RISC-V vmlinux.lds.S. This > >> is not optimal for having minimal flat kernel Image size hence this > >> patch makes BSS section as the last section in RISC-V vmlinux.lds.S. > >> > >> In addition, we make BSS section aligned to 16byte instead of PAGE > >> aligned which further reduces flat kernel Image size by few KBs. > >> > >> The flat kernel Image size of Linux-4.20-rc4 using GCC 8.2.0 is > >> 8819980 bytes with current RISC-V vmlinux.lds.S and it reduces to > >> 7991740 bytes with this patch applied using GCC 8.2.0. In summary, > >> this patch reduces Linux-4.20-rc4 flat kernel Image size by 809 KB. > >> > >> Signed-off-by: Anup Patel > >> --- > >> arch/riscv/kernel/vmlinux.lds.S | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/riscv/kernel/vmlinux.lds.S > >> b/arch/riscv/kernel/vmlinux.lds.S > >> index 65df1dfdc303..cc99eed44931 100644 > >> --- a/arch/riscv/kernel/vmlinux.lds.S > >> +++ b/arch/riscv/kernel/vmlinux.lds.S > >> @@ -74,8 +74,6 @@ SECTIONS > >> *(.sbss*) > >> } > >> > >> - BSS_SECTION(PAGE_SIZE, PAGE_SIZE, 0) > >> - > >> EXCEPTION_TABLE(0x10) > >> NOTES > >> > >> @@ -83,6 +81,8 @@ SECTIONS > >> *(.rel.dyn*) > >> } > >> > >> + BSS_SECTION(0x10, 0x10, 0x10) > >> + > >> _end = .; > >> > >> STABS_DEBUG > >> -- > >> 2.17.1 > >> > > > > Hi All, > > > > Any comment on this patch? > > Sorry, I haven't had a chance to look at it yet. Aside from the macro issue > mentioned by Nick it seems OK. I have send v2 to address Nick's comment. Regards, Anup
[PATCH v1 2/2] binderfs: reserve devices for initial mount
The binderfs instance in the initial ipc namespace will always have a reserve of 4 binder devices unless explicitly capped by specifying a lower value via the "max" mount option. This ensures when binder devices are removed (on accident or on purpose) they can always be recreated without risking that all minor numbers have already been used up. Cc: Todd Kjos Cc: Greg Kroah-Hartman Signed-off-by: Christian Brauner --- v1: - patch introduced v0: - patch not present --- drivers/android/binderfs.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c index 873adda064ac..aa635c7ea727 100644 --- a/drivers/android/binderfs.c +++ b/drivers/android/binderfs.c @@ -40,6 +40,8 @@ #define INODE_OFFSET 3 #define INTSTRLEN 21 #define BINDERFS_MAX_MINOR (1U << MINORBITS) +/* Ensure that the initial ipc namespace always has a devices available. */ +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 4) static struct vfsmount *binderfs_mnt; @@ -129,11 +131,14 @@ static int binderfs_binder_device_create(struct inode *ref_inode, struct inode *inode = NULL; struct super_block *sb = ref_inode->i_sb; struct binderfs_info *info = sb->s_fs_info; + bool use_reserve = (info->ipc_ns == _ipc_ns); /* Reserve new minor number for the new device. */ mutex_lock(_minors_mutex); if (++info->device_count <= info->mount_opts.max) - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, + minor = ida_alloc_max(_minors, + use_reserve ? BINDERFS_MAX_MINOR : + BINDERFS_MAX_MINOR_CAPPED, GFP_KERNEL); else minor = -ENOSPC; -- 2.19.1
[PATCH v1 1/2] binderfs: implement "max" mount option
Since binderfs can be mounted by userns root in non-initial user namespaces
some precautions are in order. First, a way to set a maximum on the number
of binder devices that can be allocated per binderfs instance and second, a
way to reserve a reasonable chunk of binderfs devices for the initial ipc
namespace.
A first approach as seen in [1] used sysctls similiar to devpts but was
shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
is an alternative approach which avoids sysctls completely and instead
switches to a single mount option.
Starting with this commit binderfs instances can be mounted with a limit on
the number of binder devices that can be allocated. The max= mount
option serves as a per-instance limit. If max= is set then only
number of binder devices can be allocated in this binderfs
instance.
This allows to safely bind-mount binderfs instances into unprivileged user
namespaces since userns root in a non-initial user namespace cannot change
the mount option as long as it does not own the mount namespace the
binderfs mount was created in and hence cannot drain the host of minor
device numbers
[1]: https://lore.kernel.org/lkml/20181221133909.18794-1-christ...@brauner.io/
[2]; https://lore.kernel.org/lkml/20181221163316.ga8...@kroah.com/
[3]:
https://lore.kernel.org/lkml/cahrssex+gdvw4fkkk8oznair9g5icjlyodo8hykv3o0o1jt...@mail.gmail.com/
[4]: https://lore.kernel.org/lkml/20181221192044.5yvfnuri7gdop...@brauner.io/
Cc: Todd Kjos
Cc: Greg Kroah-Hartman
Signed-off-by: Christian Brauner
---
v1:
- split reserving devices for the binderfs instance in the initial ipc
namespace into a separate patch (cf. [1])
- s/
- use simple int instead of atomic_t for counting devices since we're
incrementing and decrementing under a mutex anyway (cf. [1])
- correctly use match_int() (cf. [2])
v0:
- patch introduced
[1]: https://lore.kernel.org/lkml/20181223112944.gc27...@kroah.com/
[2]: https://lore.kernel.org/lkml/20181223135755.sqnv5ave62jtj...@brauner.io/
---
drivers/android/binderfs.c | 101 +++--
1 file changed, 96 insertions(+), 5 deletions(-)
diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 7496b10532aa..873adda064ac 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,6 +47,24 @@ static dev_t binderfs_dev;
static DEFINE_MUTEX(binderfs_minors_mutex);
static DEFINE_IDA(binderfs_minors);
+/**
+ * binderfs_mount_opts - mount options for binderfs
+ * @max: maximum number of allocatable binderfs binder devices
+ */
+struct binderfs_mount_opts {
+ int max;
+};
+
+enum {
+ Opt_max,
+ Opt_err
+};
+
+static const match_table_t tokens = {
+ { Opt_max, "max=%d" },
+ { Opt_err, NULL }
+};
+
/**
* binderfs_info - information about a binderfs mount
* @ipc_ns: The ipc namespace the binderfs mount belongs to.
@@ -55,13 +74,16 @@ static DEFINE_IDA(binderfs_minors);
* created.
* @root_gid: gid that needs to be used when a new binder device is
* created.
+ * @mount_opts: The mount options in use.
+ * @device_count: The current number of allocated binder devices.
*/
struct binderfs_info {
struct ipc_namespace *ipc_ns;
struct dentry *control_dentry;
kuid_t root_uid;
kgid_t root_gid;
-
+ struct binderfs_mount_opts mount_opts;
+ int device_count;
};
static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
@@ -110,10 +132,16 @@ static int binderfs_binder_device_create(struct inode
*ref_inode,
/* Reserve new minor number for the new device. */
mutex_lock(_minors_mutex);
- minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
+ if (++info->device_count <= info->mount_opts.max)
+ minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR,
+ GFP_KERNEL);
+ else
+ minor = -ENOSPC;
mutex_unlock(_minors_mutex);
- if (minor < 0)
+ if (minor < 0) {
+ --info->device_count;
return minor;
+ }
ret = -ENOMEM;
device = kzalloc(sizeof(*device), GFP_KERNEL);
@@ -187,6 +215,7 @@ static int binderfs_binder_device_create(struct inode
*ref_inode,
kfree(name);
kfree(device);
mutex_lock(_minors_mutex);
+ --info->device_count;
ida_free(_minors, minor);
mutex_unlock(_minors_mutex);
iput(inode);
@@ -232,6 +261,7 @@ static long binder_ctl_ioctl(struct file *file, unsigned
int cmd,
static void binderfs_evict_inode(struct inode *inode)
{
struct binder_device *device = inode->i_private;
+ struct binderfs_info *info = BINDERFS_I(inode);
clear_inode(inode);
@@ -239,6 +269,7 @@ static void binderfs_evict_inode(struct inode
Re: [PATCH] binderfs: implement "max" mount option
On Sat, Dec 22, 2018 at 10:18:06PM +0100, Christian Brauner wrote:
> Since binderfs can be mounted by userns root in non-initial user namespaces
> some precautions are in order. First, a way to set a maximum on the number
> of binder devices that can be allocated per binderfs instance and second, a
> way to reserve a reasonable chunk of binderfs devices for the initial ipc
> namespace.
> A first approach as seen in [1] used sysctls similiar to devpts but was
> shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
> is an alternative approach which avoids sysctls completely and instead
> switches to a single mount option.
>
> Starting with this commit binderfs instances can be mounted with a limit on
> the number of binder devices that can be allocated. The max= mount
> option serves as a per-instance limit. If max= is set then only
> number of binder devices can be allocated in this binderfs
> instance.
> Additionally, the binderfs instance in the initial ipc namespace will
> always have a reserve of at least 1024 binder devices unless explicitly
> capped via max=.
>
> This allows to safely bind-mount binderfs instances into unprivileged user
> namespaces since userns root in a non-initial user namespace cannot change
> the mount option as long as it does not own the mount namespace the
> binderfs mount was created in and hence cannot drain the host of minor
> device numbers
>
> [1]: https://lore.kernel.org/lkml/20181221133909.18794-1-christ...@brauner.io/
> [2]; https://lore.kernel.org/lkml/20181221163316.ga8...@kroah.com/
> [3]:
> https://lore.kernel.org/lkml/cahrssex+gdvw4fkkk8oznair9g5icjlyodo8hykv3o0o1jt...@mail.gmail.com/
> [4]: https://lore.kernel.org/lkml/20181221192044.5yvfnuri7gdop...@brauner.io/
>
> Cc: Todd Kjos
> Cc: Greg Kroah-Hartman
> Signed-off-by: Christian Brauner
> ---
> drivers/android/binderfs.c | 109 +++--
> 1 file changed, 104 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 7496b10532aa..93aee00994d4 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -39,6 +40,11 @@
> #define INODE_OFFSET 3
> #define INTSTRLEN 21
> #define BINDERFS_MAX_MINOR (1U << MINORBITS)
> +/*
> + * Ensure that the initial ipc namespace always has a good chunk of devices
> + * available.
> + */
> +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 1024)
>
> static struct vfsmount *binderfs_mnt;
>
> @@ -46,6 +52,24 @@ static dev_t binderfs_dev;
> static DEFINE_MUTEX(binderfs_minors_mutex);
> static DEFINE_IDA(binderfs_minors);
>
> +/**
> + * binderfs_mount_opts - mount options for binderfs
> + * @max: maximum number of allocatable binderfs binder devices
> + */
> +struct binderfs_mount_opts {
> + int max;
> +};
> +
> +enum {
> + Opt_max,
> + Opt_err
> +};
> +
> +static const match_table_t tokens = {
> + { Opt_max, "max=%d" },
> + { Opt_err, NULL }
> +};
> +
> /**
> * binderfs_info - information about a binderfs mount
> * @ipc_ns: The ipc namespace the binderfs mount belongs to.
> @@ -55,13 +79,16 @@ static DEFINE_IDA(binderfs_minors);
> * created.
> * @root_gid: gid that needs to be used when a new binder device is
> * created.
> + * @mount_opts: The mount options in use.
> + * @device_count: The current number of allocated binder devices.
> */
> struct binderfs_info {
> struct ipc_namespace *ipc_ns;
> struct dentry *control_dentry;
> kuid_t root_uid;
> kgid_t root_gid;
> -
> + struct binderfs_mount_opts mount_opts;
> + atomic_t device_count;
> };
>
> static inline struct binderfs_info *BINDERFS_I(const struct inode *inode)
> @@ -107,13 +134,22 @@ static int binderfs_binder_device_create(struct inode
> *ref_inode,
> struct inode *inode = NULL;
> struct super_block *sb = ref_inode->i_sb;
> struct binderfs_info *info = sb->s_fs_info;
> + bool use_reserve = (info->ipc_ns == _ipc_ns);
>
> /* Reserve new minor number for the new device. */
> mutex_lock(_minors_mutex);
> - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
> + if (atomic_inc_return(>device_count) < info->mount_opts.max)
> + minor = ida_alloc_max(_minors,
> + use_reserve ? BINDERFS_MAX_MINOR :
> + BINDERFS_MAX_MINOR_CAPPED,
> + GFP_KERNEL);
> + else
> + minor = -ENOSPC;
> mutex_unlock(_minors_mutex);
> - if (minor < 0)
> + if (minor < 0) {
> + atomic_dec(>device_count);
> return minor;
> + }
>
> ret = -ENOMEM;
> device = kzalloc(sizeof(*device), GFP_KERNEL);
> @@ -187,6 +223,7 @@ static
[PATCH] Staging: iio: adt7316: Add regmap support
Both i2c and spi drivers have functions for reading and writing
to/from registers. Remove this redundant and common code by using
regmap API.
Also remove multi_read and multi_write functions from i2c
and spi driver as they are not being used anywhere.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316-i2c.c | 101 ++--
drivers/staging/iio/addac/adt7316-spi.c | 94 +++
drivers/staging/iio/addac/adt7316.c | 147
drivers/staging/iio/addac/adt7316.h | 15 +--
4 files changed, 103 insertions(+), 254 deletions(-)
diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
b/drivers/staging/iio/addac/adt7316-i2c.c
index ac91163656b5..435b65845174 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -12,105 +12,28 @@
#include
#include
#include
+#include
#include "adt7316.h"
-/*
- * adt7316 register access by I2C
- */
-static int adt7316_i2c_read(void *client, u8 reg, u8 *data)
-{
- struct i2c_client *cl = client;
- int ret;
-
- ret = i2c_smbus_write_byte(cl, reg);
- if (ret < 0) {
- dev_err(>dev, "I2C fail to select reg\n");
- return ret;
- }
-
- ret = i2c_smbus_read_byte(client);
-
- if (!ret)
- return -EIO;
-
- if (ret < 0) {
- dev_err(>dev, "I2C read error\n");
- return ret;
- }
-
- *data = ret;
-
- return 0;
-}
-
-static int adt7316_i2c_write(void *client, u8 reg, u8 data)
-{
- struct i2c_client *cl = client;
- int ret = 0;
-
- ret = i2c_smbus_write_byte_data(cl, reg, data);
- if (ret < 0)
- dev_err(>dev, "I2C write error\n");
-
- return ret;
-}
-
-static int adt7316_i2c_multi_read(void *client, u8 reg, u8 count, u8 *data)
-{
- struct i2c_client *cl = client;
- int i, ret = 0;
-
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
-
- for (i = 0; i < count; i++) {
- ret = adt7316_i2c_read(cl, reg, [i]);
- if (ret < 0) {
- dev_err(>dev, "I2C multi read error\n");
- return ret;
- }
- }
-
- return 0;
-}
-
-static int adt7316_i2c_multi_write(void *client, u8 reg, u8 count, u8 *data)
-{
- struct i2c_client *cl = client;
- int i, ret = 0;
-
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
-
- for (i = 0; i < count; i++) {
- ret = adt7316_i2c_write(cl, reg, data[i]);
- if (ret < 0) {
- dev_err(>dev, "I2C multi write error\n");
- return ret;
- }
- }
-
- return 0;
-}
-
/*
* device probe and remove
*/
-
static int adt7316_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct adt7316_bus bus = {
- .client = client,
- .irq = client->irq,
- .read = adt7316_i2c_read,
- .write = adt7316_i2c_write,
- .multi_read = adt7316_i2c_multi_read,
- .multi_write = adt7316_i2c_multi_write,
- };
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init_i2c(client, _regmap_config);
+
+ if (IS_ERR(regmap)) {
+ dev_err(>dev, "Error initializing i2c regmap: %ld\n",
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
- return adt7316_probe(>dev, , id->name);
+ return adt7316_probe(>dev, regmap, id ? id->name : NULL,
+client->irq);
}
static const struct i2c_device_id adt7316_i2c_id[] = {
diff --git a/drivers/staging/iio/addac/adt7316-spi.c
b/drivers/staging/iio/addac/adt7316-spi.c
index e75827e326a6..9e3decb5cb77 100644
--- a/drivers/staging/iio/addac/adt7316-spi.c
+++ b/drivers/staging/iio/addac/adt7316-spi.c
@@ -11,79 +11,12 @@
#include
#include
#include
+#include
#include
#include "adt7316.h"
#define ADT7316_SPI_MAX_FREQ_HZ500
-#define ADT7316_SPI_CMD_READ 0x91
-#define ADT7316_SPI_CMD_WRITE 0x90
-
-/*
- * adt7316 register access by SPI
- */
-
-static int adt7316_spi_multi_read(void *client, u8 reg, u8 count, u8 *data)
-{
- struct spi_device *spi_dev = client;
- u8 cmd[2];
- int ret = 0;
-
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
-
- cmd[0] = ADT7316_SPI_CMD_WRITE;
- cmd[1] = reg;
-
- ret = spi_write(spi_dev, cmd, 2);
- if (ret < 0) {
- dev_err(_dev->dev, "SPI fail to select reg\n");
- return ret;
- }
-
- cmd[0] = ADT7316_SPI_CMD_READ;
-
- ret = spi_write_then_read(spi_dev, cmd, 1, data, count);
- if (ret < 0) {
- dev_err(_dev->dev, "SPI read data error\n");
Re: [PATCH] drm/fb-helper: fix leaks in error path of drm_fb_helper_fbdev_setup
Den 23.12.2018 01.55, skrev Peter Wu:
After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
"dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
have some effect). After that, drm_fb_helper_initial_config is called
which may call the "fb_probe" driver callback.
This driver callback may call drm_fb_helper_defio_init (as is done by
drm_fb_helper_generic_probe) or set a framebuffer (as is done by bochs)
as documented. These are normally cleaned up on exit by
drm_fb_helper_fbdev_teardown which also calls drm_fb_helper_fini.
If an error occurs after "fb_probe", but before setup is complete, then
calling just drm_fb_helper_fini will leak resources. This was triggered
by df2052cc922 ("bochs: convert to drm_fb_helper_fbdev_setup/teardown"):
[ 50.008030] bochsdrmfb: enable CONFIG_FB_LITTLE_ENDIAN to support this
framebuffer
[ 50.009436] bochs-drm :00:02.0: [drm:drm_fb_helper_fbdev_setup]
*ERROR* fbdev: Failed to set configuration (ret=-38)
[ 50.011456] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0
on minor 2
[ 50.013604] WARNING: CPU: 1 PID: 1 at
drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x280/0x2a0
[ 50.016175] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT
4.20.0-rc7 #1
[ 50.017732] EIP: drm_mode_config_cleanup+0x280/0x2a0
...
[ 50.023155] Call Trace:
[ 50.023155] ? bochs_kms_fini+0x1e/0x30
[ 50.023155] ? bochs_unload+0x18/0x40
This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
Reported-by: kernel test robot
Cc: Noralf Trønnes
Signed-off-by: Peter Wu
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9d64f874f965..432e0f3b9267 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2860,7 +2860,7 @@ int drm_fb_helper_fbdev_setup(struct drm_device *dev,
return 0;
err_drm_fb_helper_fini:
- drm_fb_helper_fini(fb_helper);
+ drm_fb_helper_fbdev_teardown(dev);
This change will break the error path for drm_fbdev_generic_setup()
because drm_fb_helper_generic_probe() cleans up on error but doesn't
clear drm_fb_helper->fb resulting in a double drm_framebuffer_remove().
My assumption has been that the drm_fb_helper_funcs->fb_probe callback
cleans up its resources on error. Clearly this is not the case for
bochs, so my take on this is that bochsfb_create() needs to clean up on
error.
Gerd has a patchset that switches bochs over to the generic fbdev
emulation, but ofc that doesn't help with 4.20:
https://patchwork.freedesktop.org/series/54269/
Noralf.
return ret;
}
Re: ide: Use of_node_name_eq for node name comparisons
On Wed, 2018-12-05 at 19:50:25 UTC, Rob Herring wrote: > Convert string compares of DT node names to use of_node_name_eq helper > instead. This removes direct access to the node name pointer. > > Cc: "David S. Miller" > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linux-...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/c1fa31b0fc90a80d64a334e5d35dca cheers
Re: powerpc: Use of_node_name_eq for node name comparisons
On Wed, 2018-12-05 at 19:50:18 UTC, Rob Herring wrote: > Convert string compares of DT node names to use of_node_name_eq helper > instead. This removes direct access to the node name pointer. > > A couple of open coded iterating thru the child node names are converted > to use for_each_child_of_node() instead. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Alistair Popple > Cc: Matt Porter > Cc: Anatolij Gustschin > Cc: Arnd Bergmann > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2c8e65b595cf0bf7c1413404dff9b9 cheers
Re: [v6,1/5] powerpc: add __NR_syscalls along with NR_syscalls
On Mon, 2018-12-17 at 10:40:32 UTC, Firoz Khan wrote: > NR_syscalls macro holds the number of system call exist > in powerpc architecture. We have to change the value of > NR_syscalls, if we add or delete a system call. > > One of the patch in this patch series has a script which > will generate a uapi header based on syscall.tbl file. > The syscall.tbl file contains the number of system call > information. So we have two option to update NR_syscalls > value. > > 1. Update NR_syscalls in asm/unistd.h manually by count- >ing the no.of system calls. No need to update NR_sys- >calls until we either add a new system call or delete >existing system call. > > 2. We can keep this feature in above mentioned script, >that will count the number of syscalls and keep it in >a generated file. In this case we don't need to expli- >citly update NR_syscalls in asm/unistd.h file. > > The 2nd option will be the recommended one. For that, I > added the __NR_syscalls macro in uapi/asm/unistd.h along > with NR_syscalls asm/unistd.h. The macro __NR_syscalls > also added for making the name convention same across all > architecture. While __NR_syscalls isn't strictly part of > the uapi, having it as part of the generated header to > simplifies the implementation. We also need to enclose > this macro with #ifdef __KERNEL__ to avoid side effects. > > Signed-off-by: Firoz Khan Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8a19eeeab66dfdd7c67bc8e3048ac0 cheers
Re: [v2, 01/11] powerpc/mm: Fix reporting of kernel execute faults on the 8xx
On Wed, 2018-11-28 at 09:27:04 UTC, Christophe Leroy wrote:
> On the 8xx, no-execute is set via PPP bits in the PTE. Therefore
> a no-exec fault generates DSISR_PROTFAULT error bits,
> not DSISR_NOEXEC_OR_G.
>
> This patch adds DSISR_PROTFAULT in the test mask.
>
> Fixes: d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults")
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ffca395b11c4a5a6df6d6345f794b0
cheers
Re: [v2] Powerpc/perf: Wire up PMI throttling
On Wed, 2018-11-21 at 03:56:37 UTC, Ravi Bangoria wrote:
> Commit 14c63f17b1fde ("perf: Drop sample rate when sampling is too
> slow") introduced a way to throttle PMU interrupts if we're spending
> too much time just processing those. Wire up powerpc PMI handler to
> use this infrastructure.
>
> We have throttling of the *rate* of interrupts, but this adds
> throttling based on the *time taken* to process the interrupts.
>
> Signed-off-by: Ravi Bangoria
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0c9108b083706330cd5484d121fbb0
cheers
Re: powerpc/8xx: Allow pinning IMMR TLB when using early debug console
On Thu, 2018-12-20 at 07:25:28 UTC, Christophe Leroy wrote: > CONFIG_EARLY_DEBUG_CPM requires IMMR area TLB to be pinned > otherwise it doesn't survive MMU_init, and the boot fails. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/96d19d70e1012383365c68e271d99f cheers
Re: [2/5] powerpc/4xx: Use seq_putc() in ocm_debugfs_show()
On Thu, 2018-01-11 at 18:01:33 UTC, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 11 Jan 2018 18:10:02 +0100 > > A single character (line break) should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/52930bc6e87191af3894bec302774f cheers
Re: macintosh: Use of_node_name_{eq, prefix} for node name comparisons
On Wed, 2018-12-05 at 19:50:28 UTC, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_{eq,prefix}
> helpers instead. This removes direct access to the node name pointer.
>
> This changes a single case insensitive node name comparison to case
> sensitive for "ata4". This is the only instance of a case insensitive
> comparison for all the open coded node name comparisons on powerpc.
> Searching the commit history, there doesn't appear to be any reason for
> it to be case insensitive.
>
> A couple of open coded iterating thru the child node names are converted
> to use for_each_child_of_node() instead.
>
> Cc: Benjamin Herrenschmidt
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/f1e0addca8bd7386f8cabbc64c9988
cheers
Re: [3/5] powerpc/4xx: Delete an error message for a failed memory allocation in three functions
On Thu, 2018-01-11 at 18:02:45 UTC, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 11 Jan 2018 18:28:54 +0100 > > Omit an extra message for a memory allocation failure in these functions. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a8d5dadae59f5866ac3b68cb993d53 cheers
Re: [5/5] powerpc/4xx: Delete an unnecessary return statement in two functions
On Thu, 2018-01-11 at 18:04:54 UTC, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 11 Jan 2018 18:40:23 +0100 > > The script "checkpatch.pl" pointed information out like the following. > > WARNING: void function return statements are not generally useful > > Thus remove such a statement in the affected functions. > > Signed-off-by: Markus Elfring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/ae6263cc33742d1c179510b6aadd31 cheers
Re: [1/5] powerpc/4xx: Combine four seq_printf() calls into two in ocm_debugfs_show()
On Thu, 2018-01-11 at 18:00:33 UTC, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 11 Jan 2018 18:08:08 +0100 > > Some data were printed into a sequence by four separate function calls. > Print the same data by two single function calls instead. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/b52106a040e6f86848b05be1b43174 cheers
Re: powerpc: pseries: pmem: Convert to using %pOFn instead of device_node.name
On Wed, 2018-12-05 at 19:50:17 UTC, Rob Herring wrote: > In preparation to remove the node name pointer from struct device_node, > convert printf users to use the %pOFn format specifier. pmem.c was > recently added and missed the initial conversion. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Rob Herring Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/0d1223dd9273b2ba3e965a81092a23 cheers
Re: powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"
On Tue, 2018-11-20 at 15:12:30 UTC, Alexandre Belloni wrote: > Fix a spelling mistake in a register description. > > Signed-off-by: Alexandre Belloni Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a083787680f80f2c16316a1d907bf8 cheers
[PATCH v2] soc: imx: Break dependency on SOC_IMX8MQ for GPCv2
Since this is going to be used on more SoCs than just i.MX8MQ, make the dependency here more generic. Signed-off-by: Abel Vesa Reviewed-by: Dong Aisheng --- Changes since v1: * removed the SOC_IMX7D since it's included by ARCH_MXC as suggested by Dong Aisheng. drivers/soc/imx/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig index 2112d18..d80f899 100644 --- a/drivers/soc/imx/Kconfig +++ b/drivers/soc/imx/Kconfig @@ -2,7 +2,7 @@ menu "i.MX SoC drivers" config IMX_GPCV2_PM_DOMAINS bool "i.MX GPCv2 PM domains" - depends on SOC_IMX7D || SOC_IMX8MQ || (COMPILE_TEST && OF) + depends on ARCH_MXC || (COMPILE_TEST && OF) depends on PM select PM_GENERIC_DOMAINS default y if SOC_IMX7D -- 2.7.4
[PATCH] arm64: defconfig: Add i.MX8MQ boot necessary configs
Enable all the i.MX8MQ configs necessary to boot. Signed-off-by: Abel Vesa --- arch/arm64/configs/defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 989f51b..8534bce 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -43,6 +43,7 @@ CONFIG_ARCH_HISI=y CONFIG_ARCH_MEDIATEK=y CONFIG_ARCH_MESON=y CONFIG_ARCH_MVEBU=y +CONFIG_ARCH_MXC=y CONFIG_ARCH_QCOM=y CONFIG_ARCH_RENESAS=y CONFIG_ARCH_R8A774A1=y @@ -246,6 +247,7 @@ CONFIG_NET_XGENE=y CONFIG_ATL1C=m CONFIG_MACB=y CONFIG_THUNDER_NIC_PF=y +CONFIG_FEC=y CONFIG_HIX5HD2_GMAC=y CONFIG_HNS_DSAF=y CONFIG_HNS_ENET=y @@ -320,6 +322,8 @@ CONFIG_SERIAL_MESON_CONSOLE=y CONFIG_SERIAL_SAMSUNG=y CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_TEGRA=y +CONFIG_SERIAL_IMX=y +CONFIG_SERIAL_IMX_CONSOLE=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_MSM=y CONFIG_SERIAL_MSM_CONSOLE=y @@ -366,6 +370,7 @@ CONFIG_SPI_SPIDEV=m CONFIG_SPMI=y CONFIG_PINCTRL_SINGLE=y CONFIG_PINCTRL_MAX77620=y +CONFIG_PINCTRL_IMX8MQ=y CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_MSM8916=y CONFIG_PINCTRL_MSM8994=y @@ -613,6 +618,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y CONFIG_COMMON_CLK_S2MPS11=y CONFIG_CLK_QORIQ=y CONFIG_COMMON_CLK_PWM=y +CONFIG_CLK_IMX8MQ=y CONFIG_TI_SCI_CLK=y CONFIG_COMMON_CLK_QCOM=y CONFIG_QCOM_CLK_SMD_RPM=y -- 2.7.4
Re: [PATCH 3/4] bitmap_parselist: rework input string parser
Hi Yuri, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.20-rc7 next-20181221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Yuri-Norov/rework-bitmap_parselist/20181223-175529 reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) lib/bitmap.c:679: warning: Excess function parameter 'buflen' description in '__bitmap_parselist' lib/bitmap.c:680: warning: Excess function parameter 'buflen' description in '__bitmap_parselist' >> lib/bitmap.c:680: warning: Function parameter or member 'end' not described >> in '__bitmap_parselist' lib/bitmap.c:680: warning: Excess function parameter 'buflen' description in '__bitmap_parselist' include/linux/rcutree.h:1: warning: no structured comments found kernel/rcu/tree.c:684: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/srcu.h:175: warning: Function parameter or member 'p' not described in 'srcu_dereference_notrace' include/linux/srcu.h:175: warning: Function parameter or member 'sp' not described in 'srcu_dereference_notrace' include/linux/gfp.h:1: warning: no structured comments found include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev' include/net/cfg80211.h:4439: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stats ' include/net/cfg80211.h:2838: warning: cannot understand function prototype: 'struct cfg80211_ftm_responder_stat
Re: [PATCH] binderfs: implement "max" mount option
On Sun, Dec 23, 2018 at 12:29:44PM +0100, Greg KH wrote:
> On Sat, Dec 22, 2018 at 10:18:06PM +0100, Christian Brauner wrote:
> > Since binderfs can be mounted by userns root in non-initial user namespaces
> > some precautions are in order. First, a way to set a maximum on the number
> > of binder devices that can be allocated per binderfs instance and second, a
> > way to reserve a reasonable chunk of binderfs devices for the initial ipc
> > namespace.
> > A first approach as seen in [1] used sysctls similiar to devpts but was
> > shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
> > is an alternative approach which avoids sysctls completely and instead
> > switches to a single mount option.
> >
> > Starting with this commit binderfs instances can be mounted with a limit on
> > the number of binder devices that can be allocated. The max= mount
> > option serves as a per-instance limit. If max= is set then only
> > number of binder devices can be allocated in this binderfs
> > instance.
>
> Ok, this is fine, but why such a big default? You only need 4 to run a
> modern android system, and anyone using binder outside of android is
> really too crazy to ever be using it in a container :)
>
> > Additionally, the binderfs instance in the initial ipc namespace will
> > always have a reserve of at least 1024 binder devices unless explicitly
> > capped via max=.
>
> Again, why so many? And why wouldn't that initial ipc namespace already
> have their device nodes created _before_ anything else is mounted?
Right, my issue is with re-creating devices, like if binderfs gets
unmounted or if devices get removed via rm. But we can lower the number
to 4 (see below).
>
> Some comments on the patch below:
Thanks!
>
> > +/*
> > + * Ensure that the initial ipc namespace always has a good chunk of devices
> > + * available.
> > + */
> > +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 1024)
>
> Again that seems crazy big, how about splitting this into two different
> patches, one for the max= stuff, and one for this "reserve some minors"
> thing, so we can review them separately.
Yes, let's do that. I will also lower this to 4 reserved devices.
>
> >
> > static struct vfsmount *binderfs_mnt;
> >
> > @@ -46,6 +52,24 @@ static dev_t binderfs_dev;
> > static DEFINE_MUTEX(binderfs_minors_mutex);
> > static DEFINE_IDA(binderfs_minors);
> >
> > +/**
> > + * binderfs_mount_opts - mount options for binderfs
> > + * @max: maximum number of allocatable binderfs binder devices
> > + */
> > +struct binderfs_mount_opts {
> > + int max;
> > +};
> > +
> > +enum {
> > + Opt_max,
> > + Opt_err
> > +};
> > +
> > +static const match_table_t tokens = {
> > + { Opt_max, "max=%d" },
> > + { Opt_err, NULL }
> > +};
> > +
> > /**
> > * binderfs_info - information about a binderfs mount
> > * @ipc_ns: The ipc namespace the binderfs mount belongs to.
> > @@ -55,13 +79,16 @@ static DEFINE_IDA(binderfs_minors);
> > * created.
> > * @root_gid: gid that needs to be used when a new binder device is
> > * created.
> > + * @mount_opts: The mount options in use.
> > + * @device_count: The current number of allocated binder devices.
> > */
> > struct binderfs_info {
> > struct ipc_namespace *ipc_ns;
> > struct dentry *control_dentry;
> > kuid_t root_uid;
> > kgid_t root_gid;
> > -
> > + struct binderfs_mount_opts mount_opts;
> > + atomic_t device_count;
>
> Why atomic?
>
> You should already have the lock held every time this is accessed,
> so no need to use an atomic value, just use an int.
>
> > /* Reserve new minor number for the new device. */
> > mutex_lock(_minors_mutex);
> > - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
> > + if (atomic_inc_return(>device_count) < info->mount_opts.max)
>
> No need for atomic, see, your lock is held :)
Habit, to be honest.
Thanks, fixed version to follow in a bit.
Christian
Re: remove exofs, the T10 OSD code and block/scsi bidi support V3
On 20/12/18 09:26, Christoph Hellwig wrote: > On Wed, Dec 19, 2018 at 09:01:53PM -0500, Douglas Gilbert wrote: >>> 1) reduce the size of every kernel with block layer support, and >>> even more for every kernel with scsi support >> >> By proposing the removal of bidi support from the block layer, it isn't >> just the SCSI subsystem that will be impacted. Those NVMe documents >> that you referred me to earlier in the year, in the command tables >> in 1.3c and earlier you have noticed the 2 bit direction field and >> what 11b means? Even if there aren't any bidi NVMe commands *** yet, >> the fact that NVMe's 64 byte command format has provision for 4 >> (not 2) independent data transfers (data + meta, for each direction). >> Surely NVMe will sooner or later take advantage of those ... a >> command like READ GATHERED comes to mind. > > NVMe on the other hand does have support for separate read and write > buffers as in the current SCSI bidi support, as it encodes the data > transfers in that SQE. So IFF NVMe does bidi commands it would have > to use a single buffer for data in/out, There is no such thing as "buffer" there is at first a bio, and after virtual-to-iommu mapping a scatter-gather-list. All these are currently governed by a struct request. request, bio, and sgl, have a single direction, All API's expect a single direction. All BIDI did was to say. Lets not change any API or structure but just use two of them at the same time. All the wiser is the very high level user, and the very low HW driver like iscsi. All the middlewere was never touched. In the view of a bidi target like say an osd. It all stream looks like a single "Buffer" on the wire, were some of it is read and some of it is written to. > which can be easily done ?? Did you try. It will take much more than an additional pointer sir > in the block layer without the current bidi support that chains > two struct request instances for data in and data out. > That was the all trick of not changing a single API or structure Just have two of the same thing, we already know how to handle >>> 2) reduce the size of the critical struct request structure by >>> 128 bits, thus reducing the memory used by every blk-mq driver >>> significantly, never mind the cache effects >> >> Hmm, one pointer (that is null in the non-bidi case) should be enough, >> that's 64 or 32 bits. > > Due to the way we use request chaining we need two fields at the > moment. ->special and ->next_rq. No! ->special is nothing to do with bidi. ->special is a field to be used by LLD's only and are not to be touched by block layer or transports or high level users. Request has the single ->next_rq for bidi. And could be eliminated by sharing space with the elevator info. Do you want a patch? (So in effect it can be taking 0 bytes, and yes a little bit of code) > If we'd refactor the whole thing > for the basically non-existent user we could indeed probably get it > down to a single pointer. > >> While on the subject of bidi, the order of transfers: is the data-out >> (to the target) always before the data-in or is it the target device >> that decides (depending on the semantics of the command) who is first? > > The way I read SAM data needs to be transferred to the device for > processing first, then the processing occurs and then it is transferred > out, so the order seems fixed. > Not sure what is the "SAM" above. But most of the BIDI commands I know, osd and otherwise, the order is command specific, and many times it is done in parallel. Read some bits than write some bits, rinse and repeat ... (You see in scsi the all OUT buffer is part of the actual CDB, so in effect any READ is a BIDI. The novelty here is the variable sizes and the SW stack memory targets for the different operations) >> >> Doug Gilbert >> >> *** there could already be vendor specific bidi NVMe commands out >> there (ditto for SCSI) > > For NVMe they'd need to transfer data in and out in the same buffer > to sort work, and even then only if we don't happen to be bounce > buffering using swiotlb, or using a network transport. Similarly for > SCSI only iSCSI at the moment supports bidi CDBs, so we could have > applications using vendor specific bidi commands on iSCSI, which > is exactly what we're trying to find out, but it is a bit of a very > niche use case. > Again bidi works NOW. Did not yet see the big gain, of throwing it out. Jai Maa Boaz
[GIT PULL] RAS updates for 4.21
Hi Linus,
please pull the latest ras-core-for-linus tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus
This time around we have a subsystem reorganization to offer, with the new
directory being
arch/x86/kernel/cpu/mce/
and all compilation units' names streamlined under it.
Thanks,
Boris.
-->
The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus
for you to fetch changes up to 72a8f089c382c078f8c7c1c759cb726de80d4284:
x86/mce: Restore MCE injector's module name (2018-12-19 00:04:36 +0100)
Borislav Petkov (3):
x86/mce: Streamline MCE subsystem's naming
x86/mce: Unify pr_* prefix
x86/mce: Restore MCE injector's module name
arch/x86/kernel/cpu/Makefile | 2 +-
arch/x86/kernel/cpu/{mcheck => mce}/Makefile | 10 ++
arch/x86/kernel/cpu/{mcheck/mce_amd.c => mce/amd.c} | 2 +-
arch/x86/kernel/cpu/{mcheck/mce-apei.c => mce/apei.c} | 2 +-
arch/x86/kernel/cpu/{mcheck/mce.c => mce/core.c} | 4 +---
arch/x86/kernel/cpu/{mcheck => mce}/dev-mcelog.c | 4 +---
arch/x86/kernel/cpu/{mcheck/mce-genpool.c => mce/genpool.c} | 2 +-
arch/x86/kernel/cpu/{mcheck/mce-inject.c => mce/inject.c} | 2 +-
arch/x86/kernel/cpu/{mcheck/mce_intel.c => mce/intel.c} | 2 +-
arch/x86/kernel/cpu/{mcheck/mce-internal.h => mce/internal.h} | 3 +++
arch/x86/kernel/cpu/{mcheck => mce}/p5.c | 2 ++
arch/x86/kernel/cpu/{mcheck/mce-severity.c => mce/severity.c} | 2 +-
arch/x86/kernel/cpu/{mcheck => mce}/therm_throt.c | 2 ++
arch/x86/kernel/cpu/{mcheck => mce}/threshold.c | 2 ++
arch/x86/kernel/cpu/{mcheck => mce}/winchip.c | 2 ++
15 files changed, 26 insertions(+), 17 deletions(-)
rename arch/x86/kernel/cpu/{mcheck => mce}/Makefile (61%)
rename arch/x86/kernel/cpu/{mcheck/mce_amd.c => mce/amd.c} (99%)
rename arch/x86/kernel/cpu/{mcheck/mce-apei.c => mce/apei.c} (99%)
rename arch/x86/kernel/cpu/{mcheck/mce.c => mce/core.c} (99%)
rename arch/x86/kernel/cpu/{mcheck => mce}/dev-mcelog.c (99%)
rename arch/x86/kernel/cpu/{mcheck/mce-genpool.c => mce/genpool.c} (99%)
rename arch/x86/kernel/cpu/{mcheck/mce-inject.c => mce/inject.c} (99%)
rename arch/x86/kernel/cpu/{mcheck/mce_intel.c => mce/intel.c} (99%)
rename arch/x86/kernel/cpu/{mcheck/mce-internal.h => mce/internal.h} (98%)
rename arch/x86/kernel/cpu/{mcheck => mce}/p5.c (98%)
rename arch/x86/kernel/cpu/{mcheck/mce-severity.c => mce/severity.c} (99%)
rename arch/x86/kernel/cpu/{mcheck => mce}/therm_throt.c (99%)
rename arch/x86/kernel/cpu/{mcheck => mce}/threshold.c (96%)
rename arch/x86/kernel/cpu/{mcheck => mce}/winchip.c (97%)
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
Re: x86/sgx: uapi change proposal
On Sat, Dec 22, 2018 at 10:25:02AM +0200, Jarkko Sakkinen wrote: > On Sat, Dec 22, 2018 at 10:16:49AM +0200, Jarkko Sakkinen wrote: > > On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote: > > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote: > > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just > > > > opening a new instance of /dev/sgx for each encalve? > > > > > > I think that fits better to the SCM_RIGHTS scenario i.e. you could send > > > the enclav to a process that does not have necessarily have rights to > > > /dev/sgx. Gives more robust environment to configure SGX. > > > > Sean, is this why you wanted enclave fd and anon inode and not just use > > the address space of /dev/sgx? Just taking notes of all observations. > > I'm not sure what your rationale was (maybe it was somewhere). This was > > something I made up, and this one is wrong deduction. You can easily > > get the same benefit with /dev/sgx associated fd representing the > > enclave. > > > > This all means that for v19 I'm going without enclave fd involved with > > fd to /dev/sgx representing the enclave. No anon inodes will be > > involved. > > Based on these observations I updated the uapi. > > As far as I'm concerned there has to be a solution to do EPC mapping > with a sequence: > > 1. Ping /dev/kvm to do something. > 2. KVM asks SGX core to do something. > 3. SGX core does something. > > I don't care what the something is exactly is, but KVM is the only sane > place for KVM uapi. I would be surprised if KVM maintainers didn't agree > that they don't want to sprinkle KVM uapi to random places in other > subsystems. The one option to consider to do would be to have a device driver for KVM if you really want this e.g. something like /dev/vsgx. With the current knowledge I'm not yet sure why all could not be done just through /dev/kvm. /Jarkko
[GIT PULL] x86/microcode updates for 4.21
Hi Linus, please pull the latest x86-microcode-for-linus tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-microcode-for-linus This update contains work started by Maciej to make the microcode container verification more robust against all kinds of corruption and also unify verification paths between early and late loading. The result is a set of verification routines which validate the microcode blobs before loading it on the CPU. In addition, the code is a lot more streamlined and unified. In the process, some of the aspects of patch handling and loading were simplified. All provided by Maciej S. Szmigiero and Borislav Petkov. Thanks, Boris. --> The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6: Linux 4.20-rc3 (2018-11-18 13:33:44 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-microcode-for-linus for you to fetch changes up to 2ffcbce39ea1e355eed8c6527308624f366f1c58: x86/microcode/AMD: Update copyright (2018-11-19 10:55:12 +0100) Borislav Petkov (11): x86/microcode/AMD: Move verify_patch_size() up in the file x86/microcode/AMD: Clean up per-family patch size checks x86/microcode/AMD: Cleanup verify_patch_size() more x86/microcode/AMD: Concentrate patch verification x86/microcode/AMD: Simplify patch family detection x86/microcode/AMD: Move patch family check to verify_patch() x86/microcode/AMD: Move chipset-specific check into verify_patch() x86/microcode/AMD: Change verify_patch()'s return value x86/microcode/AMD: Convert early parser to the new verification routines x86/microcode/AMD: Fix container size's type x86/microcode/AMD: Update copyright Maciej S. Szmigiero (5): x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length x86/microcode/AMD: Add microcode container verification x86/microcode/AMD: Check microcode container data in the late loader x86/microcode/AMD: Convert CPU equivalence table variable into a struct x86/microcode/AMD: Check the equivalence table size when scanning it arch/x86/kernel/cpu/microcode/amd.c | 470 +++- 1 file changed, 308 insertions(+), 162 deletions(-) -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
[GIT PULL] x86/cache updates for 4.21
Hi Linus,
please pull the latest x86-cache-for-linus tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cache-for-linus
This update contains:
- The generalization of the RDT code to accommodate the addition of AMD's
very similar implementation of the cache monitoring feature.
This entails a subsystem move into a separate and generic
arch/x86/kernel/cpu/resctrl/ directory along with adding
vendor-specific initialization and feature detection helpers.
Ontop of that is the unification of user-visible strings, both in the
resctrl filesystem error handling and Kconfig.
Provided by Babu Moger and Sherry Hurwitz.
- Code simplifications and error handling improvements by Reinette
Chatre.
And just because we're not having enough fun, this pull request
conflicts with the fs context changes in the vfs tree. Find the merge
conflict resolution (git show -M) at the end of this mail. For reference,
the merge resolution is also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git vfs-x86-cache
Thanks,
Boris.
-->
The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6:
Linux 4.20-rc3 (2018-11-18 13:33:44 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cache-for-linus
for you to fetch changes up to 52eb74339a6233c69f4e3794b69ea7c98eeeae1b:
x86/resctrl: Fix rdt_find_domain() return value and checks (2018-12-11
22:09:28 +0100)
Babu Moger (13):
x86/resctrl: Rename and move rdt files to a separate directory
x86/resctrl: Rename the RDT functions and definitions
x86/resctrl: Re-arrange the RDT init code
x86/resctrl: Move all the macros to resctrl/internal.h
x86/resctrl: Initialize the vendor-specific resource functions
x86/resctrl: Bring cbm_validate() into the resource structure
x86/resctrl: Add vendor check for the MBA software controller
x86/resctrl: Rename the config option INTEL_RDT to RESCTRL
x86/resctrl: Fixup the user-visible strings
x86/resctrl: Introduce AMD QOS feature
Documentation: Rename and update intel_rdt_ui.txt to resctrl_ui.txt
MAINTAINERS: Update resctrl filename patterns
x86/resctrl: Remove unnecessary check for cbm_validate()
Reinette Chatre (2):
x86/resctrl: Use rdt_last_cmd_puts() where possible
x86/resctrl: Fix rdt_find_domain() return value and checks
Sherry Hurwitz (1):
x86/resctrl: Add AMD's X86_FEATURE_MBA to the scattered CPUID features
Documentation/x86/{intel_rdt_ui.txt => resctrl_ui.txt}
| 9 ++-
MAINTAINERS
| 6 +-
arch/x86/Kconfig
| 22 ---
arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h}
| 28 -
arch/x86/kernel/cpu/Makefile
| 5 +-
arch/x86/kernel/cpu/resctrl/Makefile
| 4 ++
arch/x86/kernel/cpu/{intel_rdt.c => resctrl/core.c}
| 186 +++-
arch/x86/kernel/cpu/{intel_rdt_ctrlmondata.c => resctrl/ctrlmondata.c}
| 107 --
arch/x86/kernel/cpu/{intel_rdt.h => resctrl/internal.h}
| 55 +++---
arch/x86/kernel/cpu/{intel_rdt_monitor.c => resctrl/monitor.c}
| 16 +++---
arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c => resctrl/pseudo_lock.c}
| 40 ++---
arch/x86/kernel/cpu/{intel_rdt_pseudo_lock_event.h =>
resctrl/pseudo_lock_event.h} | 2 +-
arch/x86/kernel/cpu/{intel_rdt_rdtgroup.c => resctrl/rdtgroup.c}
| 61 ++--
arch/x86/kernel/cpu/scattered.c
| 7 ++-
arch/x86/kernel/process_32.c
| 4 +-
arch/x86/kernel/process_64.c
| 4 +-
include/linux/sched.h
| 2 +-
17 files changed, 385 insertions(+), 173 deletions(-)
rename Documentation/x86/{intel_rdt_ui.txt => resctrl_ui.txt} (99%)
rename arch/x86/include/asm/{intel_rdt_sched.h => resctrl_sched.h} (77%)
create mode 100644 arch/x86/kernel/cpu/resctrl/Makefile
rename arch/x86/kernel/cpu/{intel_rdt.c => resctrl/core.c} (83%)
rename arch/x86/kernel/cpu/{intel_rdt_ctrlmondata.c => resctrl/ctrlmondata.c}
(81%)
rename arch/x86/kernel/cpu/{intel_rdt.h => resctrl/internal.h} (91%)
rename arch/x86/kernel/cpu/{intel_rdt_monitor.c => resctrl/monitor.c} (98%)
rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c
Re: [PATCH 4/4] test_bitmap: add testcases for bitmap_parselist
Hi Yuri,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.20-rc7 next-20181221]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Yuri-Norov/rework-bitmap_parselist/20181223-175529
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> lib//bitmap.c:519:24: warning: incorrect type in argument 1 (different
>> address spaces)
lib//bitmap.c:519:24:expected void const volatile [noderef] *
lib//bitmap.c:519:24:got char const *str
lib//bitmap.c:735:53: warning: incorrect type in argument 2 (different
address spaces)
lib//bitmap.c:735:53:expected char const *const end
lib//bitmap.c:735:53:got char const [noderef] *
include/linux/slab.h:332:43: warning: dubious: x & !y
vim +519 lib//bitmap.c
87ac23b8 Yuri Norov 2018-12-23 515
32eb0e6b Yuri Norov 2018-12-23 516 static long get_char(char *c, const char
*str, int is_user)
32eb0e6b Yuri Norov 2018-12-23 517 {
32eb0e6b Yuri Norov 2018-12-23 518 if (unlikely(is_user))
32eb0e6b Yuri Norov 2018-12-23 @519 return __get_user(*c, str);
32eb0e6b Yuri Norov 2018-12-23 520
32eb0e6b Yuri Norov 2018-12-23 521 *c = *str;
32eb0e6b Yuri Norov 2018-12-23 522 return 0;
32eb0e6b Yuri Norov 2018-12-23 523 }
32eb0e6b Yuri Norov 2018-12-23 524
:: The code at line 519 was first introduced by commit
:: 32eb0e6b5e705132d4efef268c65730a2f2b9c41 bitmap_parselist: rework input
string parser
:: TO: Yuri Norov
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: general protection fault in put_pid
Hi Dmitry, let's simplify the mail, otherwise noone can follow: On 12/23/18 11:42 AM, Dmitry Vyukov wrote: My naive attempts to re-reproduce this failed so far. But I noticed that _all_ logs for these 3 crashes: https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909 https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac https://syzkaller.appspot.com/bug?extid=9d8b6fa6ee7636f350c1 involve low memory conditions. My gut feeling says this is not a coincidence. This is also probably the reason why all reproducers create large sem sets. There must be some bad interaction between low memory condition and semaphores/ipc namespaces. Actually was able to reproduce this with a syzkaller program: ./syz-execprog -repeat=0 -procs=10 prog ... kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8788 Comm: syz-executor8 Not tainted 4.20.0-rc7+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 Code: ad de 4c 8b 26 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48 89 da 48 39 c3 74 65 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8 00 RSP: 0018:88804faef210 EFLAGS: 00010a02 RAX: dc00 RBX: f817edba555e1f00 RCX: 831bad5f RDX: 1f02fdb74aabc3e0 RSI: 88801b8a0720 RDI: 88801b8a0728 RBP: 88804faef228 R08: f52001055401 R09: f52001055401 R10: 0001 R11: f52001055400 R12: 88802d52cc98 R13: 88801b8a0728 R14: 88801b8a0720 R15: dc00 FS: 00d24940() GS:88802d50() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004bb580 CR3: 11177005 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_del_entry include/linux/list.h:117 [inline] list_del include/linux/list.h:125 [inline] unlink_queue ipc/sem.c:786 [inline] freeary+0xddb/0x1c90 ipc/sem.c:1164 free_ipcs+0xf0/0x160 ipc/namespace.c:112 sem_exit_ns+0x20/0x40 ipc/sem.c:237 free_ipc_ns ipc/namespace.c:120 [inline] put_ipc_ns+0x55/0x160 ipc/namespace.c:152 free_nsproxy+0xc0/0x1f0 kernel/nsproxy.c:180 switch_task_namespaces+0xa5/0xc0 kernel/nsproxy.c:229 exit_task_namespaces+0x17/0x20 kernel/nsproxy.c:234 do_exit+0x19e5/0x27d0 kernel/exit.c:866 do_group_exit+0x151/0x410 kernel/exit.c:970 __do_sys_exit_group kernel/exit.c:981 [inline] __se_sys_exit_group kernel/exit.c:979 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:979 do_syscall_64+0x192/0x770 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4570e9 Code: 5d af fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b af fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffe35f12018 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: 0001 RCX: 004570e9 RDX: 00410540 RSI: 00a34c00 RDI: 0045 RBP: 004a43a4 R08: 000c R09: R10: 00d24940 R11: 0246 R12: R13: 0001 R14: R15: 0008 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace 17829b0f00569a59 ]--- RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 Code: ad de 4c 8b 26 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48 89 da 48 39 c3 74 65 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8 00 RSP: 0018:88804faef210 EFLAGS: 00010a02 RAX: dc00 RBX: f817edba555e1f00 RCX: 831bad5f RDX: 1f02fdb74aabc3e0 RSI: 88801b8a0720 RDI: 88801b8a0728 RBP: 88804faef228 R08: f52001055401 R09: f52001055401 R10: 0001 R11: f52001055400 R12: 88802d52cc98 R13: 88801b8a0728 R14: 88801b8a0720 R15: dc00 FS: 00d24940() GS:88802d50() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004bb580 CR3: 11177005 CR4: 003606e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 The prog is: unshare(0x802) semget$private(0x0, 0x4007, 0x0) kernel is on 9105b8aa50c182371533fc97db64fc8f26f051b3 and again it involved lots of oom kills, the repro eats all memory, a process getting killed, frees some memory and the process repeats. Ok, thus the above program triggers two bugs: - a huge memory leak with semaphore arrays - under OOM pressure, an oops. 1) I can reproduce the memory leak, it happens all the
Re: linux-next: Signed-off-by missing for commit in the crypto tree
On Sun, Dec 23, 2018 at 11:13:04PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
>
> Commit
>
> 6501ab5ed4d9 ("crypto: chelsio - Reset counters on cxgb4 Detach")
>
> is missing a Signed-off-by from its author.
Hi Stephen:
I believe the issue here is not a missing sign-off from the author,
but rather that the author was incorrectly set to Harsh who sent
the email rather than Atul.
Harsh, please add a From header to the patch description in future
so that the Author field is set correctly.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: general protection fault in put_pid
Hello Dmitry, On 12/23/18 10:57 AM, Dmitry Vyukov wrote: I can reproduce this infinite memory consumption with the C program: https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt But this is working as intended, right? It just creates infinite number of large semaphore sets, which reasonably consumes infinite amount of memory. Except that it also violates the memcg bound and a process can have effectively unlimited amount of such "drum memory" in semaphores. Yes, this is as intended: If you call semget(), then you can use memory, up to the limits in /proc/sys/kernel/sem. Memcg is not taken into account, an admin must set /proc/sys/kernel/sem. The default are "infinite amount of memory allowed", as this is the most sane default: We had a logic that tried to autotune (i.e.: a new namespace "inherits" a fraction of the parent namespaces memory limits), but this we more or less always wrong. -- Â Â Â Manfred
Re: remove exofs, the T10 OSD code and block/scsi bidi support V3
On 19/12/18 16:43, Christoph Hellwig wrote: > On Mon, Nov 26, 2018 at 07:11:10PM +0200, Boaz Harrosh wrote: >> On 11/11/18 15:32, Christoph Hellwig wrote: >>> The only real user of the T10 OSD protocol, the pNFS object layout >>> driver never went to the point of having shipping products, and we >>> removed it 1.5 years ago. Exofs is just a simple example without >>> real life users. >>> >> >> You have failed to say what is your motivation for this patchset? What >> is it you are trying to fix/improve. > > Drop basically unused support, which allows us to > > 1) reduce the size of every kernel with block layer support, and > even more for every kernel with scsi support Do you have numbers? its mainly code-segment so I don't think you will see any real life measurable difference. > 2) reduce the size of the critical struct request structure by > 128 bits, thus reducing the memory used by every blk-mq driver > significantly, never mind the cache effects 128 bits? I see the "struct request *next_rq;" is there another one? It could share space with elv; && flush; Do you want a patch? > 3) stop having the maintainance overhead for this code in the > block layer, which has been rather painful at times > I hear you man. Life is pain. But is it really such an overhead? I mean it is already implemented. What else is there to do? Please please show me? (Sorry for being slow) Jai Maa Boaz
linux-next: Signed-off-by missing for commit in the crypto tree
Hi Herbert,
Commit
6501ab5ed4d9 ("crypto: chelsio - Reset counters on cxgb4 Detach")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpC8B63BMDpr.pgp
Description: OpenPGP digital signature
Re: tpm_tis TPM2.0 not detected on cold boot
Hi Mimi, On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote: > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote: > > > When I remove the timeout and boot directly to the linux kernel, I get that > > "2314 TPM-self test error" since it has not finished, yet. The TPM is > > detected > > by IMA and works fine then. > > > > Some more tests showed that any delay before booting the kernel causes the > > TPM > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some > > very > > rare cases the TPM got detected. > > > > I wanted to know if the TPM is in an well initialized state at the time of > > that > > error. Since I was not able to get some test/debug kernel patches working I > > decided to try kexec. It turned out that the TPM is indeed correctly working > > and > > will be detected just fine by linux after kexec! > > No surprise here. kexec would be the equivalent of a soft reboot. Well, I am not that deep in kexec internals but isn't a soft reboot much more than a kexec? I thought kexec would "just" load the new kernel to memory and executes it while a soft reboot goes at least through some UEFI initialization. For example, my pwm fans - in fact the EC - get resetted on a soft reboot, while a kexec does not touch them. That is why I wanted to test if there is a different behaviour on kexec compared to a "real" soft reboot. If there was such difference I would have assumed a UEFI bug that does not initialize the TPM correctly. Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in the same state as before kexec and since there is no difference between sr and kexec I have the feeling there is something wrong in the kernel. Correct me if I am wrong here, please. My current workaround is to do a machine_emergency_reboot() when TPM isn't detected correctly. That is a pretty hard workaround but it seems to work for now... > > > > > Is there anyone having an idea what could be wrong here? I am willing to > > debug > > this but I have really no idea where to start :-( > > A while ago, I was "playing" with a pi. Commenting out > tpm2_do_selftest() seemed to resolve a similar problem, but that was > before James' patches. I don't know if that would make a difference > now. Hm, I will try that.. > Mimi > There is another issue but I don't know if both are related. Maybe that's just a timing issue... root@debian:~# dd if=/dev/hwrng bs=1 count=1 dd: error reading '/dev/hwrng': Operation not permitted 0+0 records in 0+0 records out 0 bytes copied, 0.755958 s, 0.0 kB/s root@debian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1 count=1 | xxd dd: error reading '/dev/hwrng': Operation not permitted 0+0 records in 0+0 records out 0 bytes copied, 0.755697 s, 0.0 kB/s 1+0 records in 1+0 records out : 52 R 1 byte copied, 0.0106268 s, 0.1 kB/s Michael
Re: [PATCH] binderfs: implement "max" mount option
On Sat, Dec 22, 2018 at 10:18:06PM +0100, Christian Brauner wrote:
> Since binderfs can be mounted by userns root in non-initial user namespaces
> some precautions are in order. First, a way to set a maximum on the number
> of binder devices that can be allocated per binderfs instance and second, a
> way to reserve a reasonable chunk of binderfs devices for the initial ipc
> namespace.
> A first approach as seen in [1] used sysctls similiar to devpts but was
> shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This
> is an alternative approach which avoids sysctls completely and instead
> switches to a single mount option.
>
> Starting with this commit binderfs instances can be mounted with a limit on
> the number of binder devices that can be allocated. The max= mount
> option serves as a per-instance limit. If max= is set then only
> number of binder devices can be allocated in this binderfs
> instance.
Ok, this is fine, but why such a big default? You only need 4 to run a
modern android system, and anyone using binder outside of android is
really too crazy to ever be using it in a container :)
> Additionally, the binderfs instance in the initial ipc namespace will
> always have a reserve of at least 1024 binder devices unless explicitly
> capped via max=.
Again, why so many? And why wouldn't that initial ipc namespace already
have their device nodes created _before_ anything else is mounted?
Some comments on the patch below:
> +/*
> + * Ensure that the initial ipc namespace always has a good chunk of devices
> + * available.
> + */
> +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 1024)
Again that seems crazy big, how about splitting this into two different
patches, one for the max= stuff, and one for this "reserve some minors"
thing, so we can review them separately.
>
> static struct vfsmount *binderfs_mnt;
>
> @@ -46,6 +52,24 @@ static dev_t binderfs_dev;
> static DEFINE_MUTEX(binderfs_minors_mutex);
> static DEFINE_IDA(binderfs_minors);
>
> +/**
> + * binderfs_mount_opts - mount options for binderfs
> + * @max: maximum number of allocatable binderfs binder devices
> + */
> +struct binderfs_mount_opts {
> + int max;
> +};
> +
> +enum {
> + Opt_max,
> + Opt_err
> +};
> +
> +static const match_table_t tokens = {
> + { Opt_max, "max=%d" },
> + { Opt_err, NULL }
> +};
> +
> /**
> * binderfs_info - information about a binderfs mount
> * @ipc_ns: The ipc namespace the binderfs mount belongs to.
> @@ -55,13 +79,16 @@ static DEFINE_IDA(binderfs_minors);
> * created.
> * @root_gid: gid that needs to be used when a new binder device is
> * created.
> + * @mount_opts: The mount options in use.
> + * @device_count: The current number of allocated binder devices.
> */
> struct binderfs_info {
> struct ipc_namespace *ipc_ns;
> struct dentry *control_dentry;
> kuid_t root_uid;
> kgid_t root_gid;
> -
> + struct binderfs_mount_opts mount_opts;
> + atomic_t device_count;
Why atomic?
You should already have the lock held every time this is accessed,
so no need to use an atomic value, just use an int.
> /* Reserve new minor number for the new device. */
> mutex_lock(_minors_mutex);
> - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, GFP_KERNEL);
> + if (atomic_inc_return(>device_count) < info->mount_opts.max)
No need for atomic, see, your lock is held :)
thanks,
greg k-h
Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver
Hi! > > So the little elves have been slowly working to get voice calls > > working on droid 4 with the mainline kernel. And just in time for the > > upcoming holidays, it might be possible to call friends and relatives. > > > > I've pushed out an experimental branch containing serdev ts 27.010 > > UART multiplexing support. That contains a serdev core driver for the > > mdm6600 modem (that also now idles the modem for PM), support for Alsa > > ASoC voice codec and mixer, and a GNSS driver for the GPS. > > > > Where it does not make sense to do a kernel serdev driver, I've > > exposed the rest of the available 27.010 channels as ten /dev/motmdm* > > character devices. There's /dev/motmdm1 for AT commands to dial voice > > calls, /dev/motmdm3 for SMS eventually, and I think there's also a SIM > > card reader at /dev/motmdm10. Then /dev/motmdm7 seems to be just an > > echo channel. The other channels are still a bit of a mystery. > > I suspected it does not work in non-modular case, so I tried with > modules: > > root@devuan:/my/ko# insmod gnss.ko > root@devuan:/my/ko# insmod gnss-motmdm.ko > insmod: ERROR: could not insert module gnss-motmdm.ko: Unknown symbol > in module > root@devuan:/my/ko# insmod n_gsm.ko > root@devuan:/my/ko# insmod snd-soc-motmdm.ko > insmod: ERROR: could not insert module snd-soc-motmdm.ko: Unknown > symbol in module > root@devuan:/my/ko# insmod motorola-mdm.ko > root@devuan:/my/ko# insmod snd-soc-motmdm.ko > root@devuan:/my/ko# insmod gnss-motmdm.ko > root@devuan:/my/ko# ... > ...do I need to make devices manually or some udev rules? > > user@devuan:~$ cat /proc/devices | grep motmdm > user@devuan:~$ cat /proc/devices | grep gnss > 242 gnss > user@devuan:~$ > > Hmm, I suspect the driver just did not recognize the hw. I added some printks to motmdm_probe, and they don't appear to be called. I wonder if I'm missing something else in the config? I do have serial root@devuan:/my/ko# ls -al /dev/ttyS0 crw-rw 1 root dialout 4, 64 Dec 23 11:52 /dev/ttyS0 but not gsm multiplex: root@devuan:/my/ko# ls -al /dev/gsm* ls: cannot access '/dev/gsm*': No such file or directory Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH V2 00/10] unify the interface of the proportional-share policy in blkio/io
> Il giorno 18 dic 2018, alle ore 18:22, Paolo Valente > ha scritto: > > > >> Il giorno 18 dic 2018, alle ore 17:41, Tejun Heo ha >> scritto: >> >> Hello, Paolo. >> >> On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote: >>> If Tejun cannot see any solution to his concern, then can we just >>> switch to this extension, considering that >>> - for non-shared names the interface is *identical* to the current >>> one; >>> - by using this new interface, and getting feedback we could >>> understand how to better handle Tejun's concern? >>> A lot of systems do use weights, and people don't even know that these >>> systems don't work correctly in blk-mq. And they won't work correctly >>> in any available configuration from 4.21, if we don't fix this problem. >> >> So, when seen from userland, how it should behave isn't vague or >> complicated. For a given device and policy type, there can be only >> one implementation active. > > Yes, but the problem is the opposite. You may have > - two different policies, with the same interface parameter, > - one active on one device > - the other one active on another device > > In that case, statistics from one policy necessarily differ from > statistics from the other policy. > > In this respect, in a system with more than one drive it already > happens that the same policy is active on different devices. When > printing a statistics interface file for the policy, the output will > be a list of separate statistics, with a bunch of statistics *for > each* drive (plus a grand total in some cases). > > So, our proposal simply extends this scheme in the most natural way: > if, now, also two or more policies share the same statistics file, > then the output will be a list of separate statistics, one for each > policy. The statistics for each policy will be tagged with the policy > name, and will have the same identical form as above. It seems the > most natural hierarchical extension of the same scheme. > Maybe my generic description didn't highlight how plain are. If you print, e.g., io_serviced with the current interface, you get -- 8:0 Read 4291168 8:0 Write 2181577 8:0 Sync 5897755 8:0 Async 574990 8:0 Total 6472745 Total 6472745 -- With the new, interface, you get *the same output*, if only one policy is attached to this interface file. In, instead - two policies share the the file, because one is active on a device and one on another device - these policies are named, e.g., bfq and pol2 then you get (device number and statistics invented): -- bfq: 8:0 Read 4291168 8:0 Write 2181577 8:0 Sync 5897755 8:0 Async 574990 8:0 Total 6472745 Total 6472745 pol2: 16:0 Read 238768 16:0 Write 323123 16:0 Sync 43243 16:0 Async 432432 16:0 Total 412435 Total 4341244 -- So you see the per-device statistics as before, without the problem of inventing a new set of names for every new policy that has the same interface files of an existing policy. Tejun, let's try to converge, to whatever solution you prefer. 4.21 is coming ... and the legacy proportional share interface will be gone with cfq. This will break legacy code using the proportional-share interface on top of bfq. This code may just fail when trying to use interface files that don't exist any longer. Thanks, Paolo > At any rate, if you don't like it, just tell us how you prefer it > done. Do you prefer the sharing of statistics file to be simply > forbidden? (If this can be done.) I think such an incomplete solution > would preserve part of the current mess; but, if this allows us to > exit from this impasse, then it is ok for me. > > *Any* feasible option is ok for me. Just pick one. > >> It doesn't make sense to have two weight >> mechanisms active on one device, right? > > (Un)fortunately, the problem are not weights. There won't be two > weights for two policies expiring a weight parameter. The problems > concerns statistics. See above. > > >> So, the interface should only >> present what makes sense to the user for both configuration knobs and >> statistics, and that'd be a hard requirement because we don't want to >> present confusing spurious information to userspace. >> >> There seemd to have been significant misunderstandings as to what the >> requirements are when this was discussed way back, so idk what the >> good path forward is at this point. Just keep the current names? >> > > I don't clearly understand how "just picking the current names" is a > way forward, but if we do not make this extension, in a way or the > other, then two policies will simply not be allowed to share the same > interface files. And we will be still at the starting point. > > Thanks, > Paolo > >> Thanks. >> >> -- >> tejun > > -- > You received this message because you are subscribed to the Google Groups > "bfq-iosched" group. > To unsubscribe from this group and stop
Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn
Den 23-12-2018 kl. 01:28, skrev Linus Torvalds: On Sat, Dec 22, 2018 at 3:07 PM Christian Brauner wrote: However, for this case should I resend the revert? Since I was pointed at the original email thread, I just picked it up from there directly. It still applied cleanly, nothing had changed in that area. Linus This should also be picked up for 4.19 lts Greg, it's now upstream as: From 94f82008ce30e2624537d240d64ce718255e0b80 Mon Sep 17 00:00:00 2001 From: Christian Brauner Date: Thu, 5 Jul 2018 17:51:20 +0200 Subject: Revert "vfs: Allow userns root to call mknod on owned filesystems." -- Thomas
Re: general protection fault in put_pid
On Sun, Dec 23, 2018 at 11:30 AM Dmitry Vyukov wrote: > > On Sun, Dec 23, 2018 at 10:57 AM Dmitry Vyukov wrote: > > > > On Sun, Dec 23, 2018 at 8:37 AM Dmitry Vyukov wrote: > > > > > > On Sat, Dec 22, 2018 at 8:07 PM Manfred Spraul > > > wrote: > > > > > > > > Hi Dmitry, > > > > > > > > On 12/20/18 4:36 PM, Dmitry Vyukov wrote: > > > > > On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul > > > > > wrote: > > > > >> Hello Dmitry, > > > > >> > > > > >> On 12/12/18 11:55 AM, Dmitry Vyukov wrote: > > > > >>> On Tue, Dec 11, 2018 at 9:23 PM syzbot > > > > >>> wrote: > > > > Hello, > > > > > > > > syzbot found the following crash on: > > > > > > > > HEAD commit:f5d582777bcb Merge branch 'for-linus' of > > > > git://git.kernel... > > > > git tree: upstream > > > > console output: > > > > https://syzkaller.appspot.com/x/log.txt?x=135bc54740 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac > > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > > syz repro: > > > > https://syzkaller.appspot.com/x/repro.syz?x=16803afb40 > > > > >>> +Manfred, this looks similar to the other few crashes related to > > > > >>> semget$private(0x0, 0x4000, 0x3f) that you looked at. > > > > >> I found one unexpected (incorrect?) locking, see the attached patch. > > > > >> > > > > >> But I doubt that this is the root cause of the crashes. > > > > > > > > > > But why? These one-off sporadic crashes reported by syzbot looks > > > > > exactly like a subtle race and your patch touches sem_exit_ns involved > > > > > in all reports. > > > > > So if you don't spot anything else, I would say close these 3 reports > > > > > with this patch (I see you already included Reported-by tags which is > > > > > great!) and then wait for syzbot reaction. Since we got 3 of them, if > > > > > it's still not fixed I would expect that syzbot will be able to > > > > > retrigger this later again. > > > > > > > > As I wrote, unless semop() is used, sma->use_global_lock is always 9 and > > > > nothing can happen. > > > > > > > > Every single-operation semop() reduces use_global_lock by one, i.e a > > > > single semop call as done here cannot trigger the bug: > > > > > > > > https://syzkaller.appspot.com/text?tag=ReproSyz=16803afb40 > > > > > > It contains "repeat":true,"procs":6, which means that it run 6 > > > processes running this test in infinite loop. The last mark about > > > number of tests executed was: > > > 2018/12/11 18:38:02 executed programs: 2955 > > > > > > > But, one more finding: > > > > > > > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac > > > > > > > > https://syzkaller.appspot.com/text?tag=CrashLog=109ecf6e40 > > > > > > > > The log file contain 1080 lines like these: > > > > > > > > > semget$private(..., 0x4003, ...) > > > > > > > > > > semget$private(..., 0x4006, ...) > > > > > > > > > > semget$private(..., 0x4007, ...) > > > > > > > > It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an > > > > allocation in the 4 MB kmalloc buffer: > > > > > > > > > [ 1201.210245] kmalloc-4194304 4698112KB4698112KB > > > > > > > > > i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the > > > > semaphore arrays?? > > > > > > /\/\/\/\/\/\ > > > > > > Ha, this is definitely not healthy. > > > > I can reproduce this infinite memory consumption with the C program: > > https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt > > > > But this is working as intended, right? It just creates infinite > > number of large semaphore sets, which reasonably consumes infinite > > amount of memory. > > Except that it also violates the memcg bound and a process can have > > effectively unlimited amount of such "drum memory" in semaphores. > > > > > > > > > > > > This one looks similar: > > > > > > > > https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909 > > > > > > > > except that the array sizes are mixed, and thus there are kmalloc-1M and > > > > kmalloc-2M as well. > > > > > > > > (and I did not count the number of semget calls) > > > > > > > > > > > > The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), > > > > correct? > > > > > > > > I.e. no CLONE_NEWUSER. > > > > > > > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523 > > > > > > CLONE_NEWUSER is used on some instances as well: > > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1765 > > > This crash happened on 2 different instances and 1 of them uses > > > CLONE_NEWUSER and another does not. > > > If it's important because of CAP_ADMIN in IPC namespace, then all > > > instances should have it (instances that don't use NEWUSER are just > > >
Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver
Hi! > So the little elves have been slowly working to get voice calls > working on droid 4 with the mainline kernel. And just in time for the > upcoming holidays, it might be possible to call friends and relatives. > > I've pushed out an experimental branch containing serdev ts 27.010 > UART multiplexing support. That contains a serdev core driver for the > mdm6600 modem (that also now idles the modem for PM), support for Alsa > ASoC voice codec and mixer, and a GNSS driver for the GPS. > > Where it does not make sense to do a kernel serdev driver, I've > exposed the rest of the available 27.010 channels as ten /dev/motmdm* > character devices. There's /dev/motmdm1 for AT commands to dial voice > calls, /dev/motmdm3 for SMS eventually, and I think there's also a SIM > card reader at /dev/motmdm10. Then /dev/motmdm7 seems to be just an > echo channel. The other channels are still a bit of a mystery. I suspected it does not work in non-modular case, so I tried with modules: root@devuan:/my/ko# insmod gnss.ko root@devuan:/my/ko# insmod gnss-motmdm.ko insmod: ERROR: could not insert module gnss-motmdm.ko: Unknown symbol in module root@devuan:/my/ko# insmod n_gsm.ko root@devuan:/my/ko# insmod snd-soc-motmdm.ko insmod: ERROR: could not insert module snd-soc-motmdm.ko: Unknown symbol in module root@devuan:/my/ko# insmod motorola-mdm.ko root@devuan:/my/ko# insmod snd-soc-motmdm.ko root@devuan:/my/ko# insmod gnss-motmdm.ko root@devuan:/my/ko# But... root@devuan:/my/ko# ls -al /dev/motmdm* ls: cannot access '/dev/motmdm*': No such file or directory root@devuan:/my/ko# ls -al /dev/gnss* ls: cannot access '/dev/gnss*': No such file or directory root@devuan:/my/ko# [ 116.25] gnss: GNSS driver registered with major 242 [ 119.892547] gnss_motmdm: Unknown symbol motmdm_register_dlci (err -2) [ 119.899444] gnss_motmdm: Unknown symbol motmdm_unregister_dlci (err -2) [ 129.145935] snd_soc_motmdm: Unknown symbol motmdm_register_dlci (err -2) [ 129.153106] snd_soc_motmdm: Unknown symbol motmdm_unregister_dlci (err -2) [ 131.120361] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 161.190216] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 191.270263] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 221.360107] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 251.429962] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 281.509643] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [ 292.816436] g_ether gadget: packet filter 0e [ 292.825256] g_ether gadget: ecm req21.43 v000e i l0 ...do I need to make devices manually or some udev rules? user@devuan:~$ cat /proc/devices | grep motmdm user@devuan:~$ cat /proc/devices | grep gnss 242 gnss user@devuan:~$ Hmm, I suspect the driver just did not recognize the hw. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: general protection fault in put_pid
On Sun, Dec 23, 2018 at 10:57 AM Dmitry Vyukov wrote: > > On Sun, Dec 23, 2018 at 8:37 AM Dmitry Vyukov wrote: > > > > On Sat, Dec 22, 2018 at 8:07 PM Manfred Spraul > > wrote: > > > > > > Hi Dmitry, > > > > > > On 12/20/18 4:36 PM, Dmitry Vyukov wrote: > > > > On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul > > > > wrote: > > > >> Hello Dmitry, > > > >> > > > >> On 12/12/18 11:55 AM, Dmitry Vyukov wrote: > > > >>> On Tue, Dec 11, 2018 at 9:23 PM syzbot > > > >>> wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:f5d582777bcb Merge branch 'for-linus' of > > > git://git.kernel... > > > git tree: upstream > > > console output: > > > https://syzkaller.appspot.com/x/log.txt?x=135bc54740 > > > kernel config: > > > https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23 > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac > > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > > syz repro: > > > https://syzkaller.appspot.com/x/repro.syz?x=16803afb40 > > > >>> +Manfred, this looks similar to the other few crashes related to > > > >>> semget$private(0x0, 0x4000, 0x3f) that you looked at. > > > >> I found one unexpected (incorrect?) locking, see the attached patch. > > > >> > > > >> But I doubt that this is the root cause of the crashes. > > > > > > > > But why? These one-off sporadic crashes reported by syzbot looks > > > > exactly like a subtle race and your patch touches sem_exit_ns involved > > > > in all reports. > > > > So if you don't spot anything else, I would say close these 3 reports > > > > with this patch (I see you already included Reported-by tags which is > > > > great!) and then wait for syzbot reaction. Since we got 3 of them, if > > > > it's still not fixed I would expect that syzbot will be able to > > > > retrigger this later again. > > > > > > As I wrote, unless semop() is used, sma->use_global_lock is always 9 and > > > nothing can happen. > > > > > > Every single-operation semop() reduces use_global_lock by one, i.e a > > > single semop call as done here cannot trigger the bug: > > > > > > https://syzkaller.appspot.com/text?tag=ReproSyz=16803afb40 > > > > It contains "repeat":true,"procs":6, which means that it run 6 > > processes running this test in infinite loop. The last mark about > > number of tests executed was: > > 2018/12/11 18:38:02 executed programs: 2955 > > > > > But, one more finding: > > > > > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac > > > > > > https://syzkaller.appspot.com/text?tag=CrashLog=109ecf6e40 > > > > > > The log file contain 1080 lines like these: > > > > > > > semget$private(..., 0x4003, ...) > > > > > > > > semget$private(..., 0x4006, ...) > > > > > > > > semget$private(..., 0x4007, ...) > > > > > > It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an > > > allocation in the 4 MB kmalloc buffer: > > > > > > > [ 1201.210245] kmalloc-4194304 4698112KB4698112KB > > > > > > > i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the > > > semaphore arrays?? > > > > /\/\/\/\/\/\ > > > > Ha, this is definitely not healthy. > > I can reproduce this infinite memory consumption with the C program: > https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt > > But this is working as intended, right? It just creates infinite > number of large semaphore sets, which reasonably consumes infinite > amount of memory. > Except that it also violates the memcg bound and a process can have > effectively unlimited amount of such "drum memory" in semaphores. > > > > > > > This one looks similar: > > > > > > https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909 > > > > > > except that the array sizes are mixed, and thus there are kmalloc-1M and > > > kmalloc-2M as well. > > > > > > (and I did not count the number of semget calls) > > > > > > > > > The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), correct? > > > > > > I.e. no CLONE_NEWUSER. > > > > > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523 > > > > CLONE_NEWUSER is used on some instances as well: > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1765 > > This crash happened on 2 different instances and 1 of them uses > > CLONE_NEWUSER and another does not. > > If it's important because of CAP_ADMIN in IPC namespace, then all > > instances should have it (instances that don't use NEWUSER are just > > root). My naive attempts to re-reproduce this failed so far. But I noticed that _all_ logs for these 3 crashes: https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909 https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac https://syzkaller.appspot.com/bug?extid=9d8b6fa6ee7636f350c1 involve low
[PATCH] arm64: dts: rockchip: enable analog audio node for rock64
The Rock64 boards has analog audio jack on it. RK3328 can output
analog audio signal using I2S1 and ACODEC core.
This patch adds sound node for analog audio for Rock64.
Signed-off-by: Katsuhiro Suzuki
---
This patch depends on the following ACODEC node patch. If ACODEC
patch is not good to you, please drop this patch too.
https://lkml.org/lkml/2018/12/23/53
.../arm64/boot/dts/rockchip/rk3328-rock64.dts | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index bd937d68ca3b..0a71e1287a1b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -66,7 +66,8 @@
sound {
compatible = "audio-graph-card";
label = "rockchip,rk3328";
- dais = <_p0>;
+ dais = <_p0
+ _p0>;
};
spdif-dit {
@@ -81,6 +82,17 @@
};
};
+ {
+ status = "okay";
+ #sound-dai-cells = <0>;
+
+ port@0 {
+ codec_p0_0: endpoint {
+ remote-endpoint = <_p0_0>;
+ };
+ };
+};
+
{
cpu-supply = <_arm>;
};
@@ -243,6 +255,19 @@
};
};
+ {
+ status = "okay";
+ #sound-dai-cells = <0>;
+
+ i2s1_p0: port {
+ i2s1_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <_p0_0>;
+ };
+ };
+};
+
_domains {
status = "okay";
--
2.19.2
[PATCH] arm64: dts: rockchip: add rk3328 ACODEC node
This patch adds audio codec (ACODEC) node that converts to analog
audio signal from I2S for rk3328.
Signed-off-by: Katsuhiro Suzuki
---
This patch depends on Rockcihp RK3328 ACODEC driver patches that were
applied in ALSA SoC tree. We can see the patches on this thread.
https://lkml.org/lkml/2018/12/20/665
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index ecd7f19c3542..0f02b1dc87e3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -672,6 +672,16 @@
};
};
+ codec: codec@ff41 {
+ compatible = "rockchip,rk3328-codec";
+ reg = <0x0 0xff41 0x0 0x1000>;
+ rockchip,grf = <>;
+ clocks = < PCLK_ACODECPHY>, < SCLK_I2S1>;
+ clock-names = "pclk", "mclk";
+ #sound-dai-cells = <0>;
+ status = "disabled";
+ };
+
hdmiphy: phy@ff43 {
compatible = "rockchip,rk3328-hdmi-phy";
reg = <0x0 0xff43 0x0 0x1>;
--
2.19.2
Re: general protection fault in put_pid
On Sun, Dec 23, 2018 at 8:37 AM Dmitry Vyukov wrote: > > On Sat, Dec 22, 2018 at 8:07 PM Manfred Spraul > wrote: > > > > Hi Dmitry, > > > > On 12/20/18 4:36 PM, Dmitry Vyukov wrote: > > > On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul > > > wrote: > > >> Hello Dmitry, > > >> > > >> On 12/12/18 11:55 AM, Dmitry Vyukov wrote: > > >>> On Tue, Dec 11, 2018 at 9:23 PM syzbot > > >>> wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:f5d582777bcb Merge branch 'for-linus' of > > git://git.kernel... > > git tree: upstream > > console output: > > https://syzkaller.appspot.com/x/log.txt?x=135bc54740 > > kernel config: > > https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23 > > dashboard link: > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac > > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > > syz repro: > > https://syzkaller.appspot.com/x/repro.syz?x=16803afb40 > > >>> +Manfred, this looks similar to the other few crashes related to > > >>> semget$private(0x0, 0x4000, 0x3f) that you looked at. > > >> I found one unexpected (incorrect?) locking, see the attached patch. > > >> > > >> But I doubt that this is the root cause of the crashes. > > > > > > But why? These one-off sporadic crashes reported by syzbot looks > > > exactly like a subtle race and your patch touches sem_exit_ns involved > > > in all reports. > > > So if you don't spot anything else, I would say close these 3 reports > > > with this patch (I see you already included Reported-by tags which is > > > great!) and then wait for syzbot reaction. Since we got 3 of them, if > > > it's still not fixed I would expect that syzbot will be able to > > > retrigger this later again. > > > > As I wrote, unless semop() is used, sma->use_global_lock is always 9 and > > nothing can happen. > > > > Every single-operation semop() reduces use_global_lock by one, i.e a > > single semop call as done here cannot trigger the bug: > > > > https://syzkaller.appspot.com/text?tag=ReproSyz=16803afb40 > > It contains "repeat":true,"procs":6, which means that it run 6 > processes running this test in infinite loop. The last mark about > number of tests executed was: > 2018/12/11 18:38:02 executed programs: 2955 > > > But, one more finding: > > > > https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac > > > > https://syzkaller.appspot.com/text?tag=CrashLog=109ecf6e40 > > > > The log file contain 1080 lines like these: > > > > > semget$private(..., 0x4003, ...) > > > > > > semget$private(..., 0x4006, ...) > > > > > > semget$private(..., 0x4007, ...) > > > > It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an > > allocation in the 4 MB kmalloc buffer: > > > > > [ 1201.210245] kmalloc-4194304 4698112KB4698112KB > > > > > i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the > > semaphore arrays?? > > /\/\/\/\/\/\ > > Ha, this is definitely not healthy. I can reproduce this infinite memory consumption with the C program: https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d8e6/gistfile1.txt But this is working as intended, right? It just creates infinite number of large semaphore sets, which reasonably consumes infinite amount of memory. Except that it also violates the memcg bound and a process can have effectively unlimited amount of such "drum memory" in semaphores. > > This one looks similar: > > > > https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909 > > > > except that the array sizes are mixed, and thus there are kmalloc-1M and > > kmalloc-2M as well. > > > > (and I did not count the number of semget calls) > > > > > > The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), correct? > > > > I.e. no CLONE_NEWUSER. > > > > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523 > > CLONE_NEWUSER is used on some instances as well: > https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1765 > This crash happened on 2 different instances and 1 of them uses > CLONE_NEWUSER and another does not. > If it's important because of CAP_ADMIN in IPC namespace, then all > instances should have it (instances that don't use NEWUSER are just > root).
[PATCH] staging: mt29f_spinand: add SPDX identifiers
This satisfies a checkpatch warning and is the preferred method for notating the license. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. Signed-off-by: Michael Straube --- drivers/staging/mt29f_spinand/mt29f_spinand.c | 11 +-- drivers/staging/mt29f_spinand/mt29f_spinand.h | 12 ++-- 2 files changed, 3 insertions(+), 20 deletions(-) diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c index def8a1f57d1c..8630f7012957 100644 --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c @@ -1,17 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Copyright (c) 2003-2013 Broadcom Corporation * * Copyright (c) 2009-2010 Micron Technology, Inc. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version 2 - * of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. */ #include diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.h b/drivers/staging/mt29f_spinand/mt29f_spinand.h index 457dc7ffdaf1..38837cc6421c 100644 --- a/drivers/staging/mt29f_spinand/mt29f_spinand.h +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.h @@ -1,17 +1,9 @@ -/*- +/* SPDX-License-Identifier: GPL-2.0 */ +/* * Copyright 2013 Broadcom Corporation * * Copyright (c) 2009-2010 Micron Technology, Inc. * - * This software is licensed under the terms of the GNU General Public - * License version 2, as published by the Free Software Foundation, and - * may be copied, distributed, and modified under those terms. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * * Henry Pan * * based on nand.h -- 2.20.1
[PATCH 4/4] test_bitmap: add testcases for bitmap_parselist
Add tests for non-number character, empty regions, integer overflow.
Signed-off-by: Yury Norov
---
lib/test_bitmap.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6cd7d0740005..7580dd6ac599 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -224,7 +224,8 @@ static const unsigned long exp[] __initconst = {
BITMAP_FROM_U64(0x),
BITMAP_FROM_U64(0xfffe),
BITMAP_FROM_U64(0xULL),
- BITMAP_FROM_U64(0xULL)
+ BITMAP_FROM_U64(0xULL),
+ BITMAP_FROM_U64(0),
};
static const unsigned long exp2[] __initconst = {
@@ -247,19 +248,34 @@ static const struct test_bitmap_parselist
parselist_tests[] __initconst = {
{0, "1-31:4/4", [9 * step], 32, 0},
{0, "0-31:1/4,32-63:2/4", [10 * step], 64, 0},
{0, "0-31:3/4,32-63:4/4", [11 * step], 64, 0},
+ {0, " ,, 0-31:3/4 ,, 32-63:4/4 ,, ", [11 * step], 64, 0},
{0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4", exp2, 128, 0},
{0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
+ {0, "", [12], 8, 0},
+ {0, "\n", [12], 8, 0},
+ {0, ",, ,, , , ,", [12], 8, 0},
+ {0, " , ,, , , ", [12], 8, 0},
+ {0, " , ,, , , \n", [12], 8, 0},
+
{-EINVAL, "-1", NULL, 8, 0},
{-EINVAL, "-0", NULL, 8, 0},
{-EINVAL, "10-1", NULL, 8, 0},
{-EINVAL, "0-31:", NULL, 8, 0},
{-EINVAL, "0-31:0", NULL, 8, 0},
+ {-EINVAL, "0-31:0/", NULL, 8, 0},
{-EINVAL, "0-31:0/0", NULL, 8, 0},
{-EINVAL, "0-31:1/0", NULL, 8, 0},
{-EINVAL, "0-31:10/1", NULL, 8, 0},
+ {-EOVERFLOW, "0-98765432123456789:10/1", NULL, 8, 0},
+
+ {-EINVAL, "a-31", NULL, 8, 0},
+ {-EINVAL, "0-a1", NULL, 8, 0},
+ {-EINVAL, "a-31:10/1", NULL, 8, 0},
+ {-EINVAL, "0-31:a/1", NULL, 8, 0},
+ {-EINVAL, "0-\n", NULL, 8, 0},
};
static void __init test_bitmap_parselist(void)
--
2.17.1
[PATCH 0/4] rework bitmap_parselist
bitmap_parselist evolved from a pretty simple idea for long and now lacks for refactoring. It is not structured, has nested loops and a set of opaque-named variables. All this leads to extremely hard understanding of the code. Once during the optimization of it I missed a scenario which leads to kernel hangup. Tetsuo Handa spotted this and found it simpler to rewrite the code instead fixing it. (Though, that attempt had some flaws.) https://lkml.org/lkml/2018/4/1/93 Things are more complicated than they may be because bitmap_parselist() is part of user interface, and its behavior should not change. In this patchset __bitmap_parselist() is split to a set of smaller functions doing only one thing. Yury Norov (4): bitmap_parselist: don't calculate length of the input string bitmap_parselist: move part of logic to helpers bitmap_parselist: rework input string parser test_bitmap: add testcases for bitmap_parselist lib/bitmap.c | 294 ++ lib/test_bitmap.c | 18 ++- 2 files changed, 208 insertions(+), 104 deletions(-) -- 2.17.1
[PATCH 3/4] bitmap_parselist: rework input string parser
The requirement for this rework is to keep the __bitmap_parselist()
copy-less and single-pass but make it more readable and maintainable by
splitting into logical parts and removing explicit nested cycles and
opaque local variables.
__bitmap_parselist() can parse userspace inputs and therefore we cannot
use simple_strtoul() to parse numbers.
Signed-off-by: Yury Norov
---
lib/bitmap.c | 247 ++-
1 file changed, 148 insertions(+), 99 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index a60fd9723677..edc7068c28a6 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -513,6 +513,140 @@ static int bitmap_check_region(const struct region *r)
return 0;
}
+static long get_char(char *c, const char *str, int is_user)
+{
+ if (unlikely(is_user))
+ return __get_user(*c, str);
+
+ *c = *str;
+ return 0;
+}
+
+static const char *bitmap_getnum(unsigned int *num, const char *str,
+ const char *const end, int is_user)
+{
+ unsigned int n = 0;
+ const char *_str;
+ long ret;
+ char c;
+
+ for (_str = str, *num = 0; _str <= end; _str++) {
+ ret = get_char(, _str, is_user);
+ if (ret)
+ return (char *)ret;
+
+ if (!isdigit(c)) {
+ if (_str == str)
+ return (char *)-EINVAL;
+
+ goto out;
+ }
+
+ *num = *num * 10 + (c - '0');
+ if (*num < n)
+ return (char *)-EOVERFLOW;
+
+ n = *num;
+ }
+
+out:
+ return _str;
+}
+
+static const char *bitmap_find_region(const char *str,
+ const char *const end, int is_user)
+{
+ long ret;
+ char c;
+
+ for (; str < end; str++) {
+ ret = get_char(, str, is_user);
+ if (ret)
+ return (char *)ret;
+
+ /* Unexpected end of line. */
+ if (c == 0 || c == '\n')
+ return NULL;
+
+ /*
+* The format allows commas and whitespases
+* at the beginning of the region, so skip it.
+*/
+ if (!isspace(c) && c != ',')
+ break;
+ }
+
+ return str;
+}
+
+static const char *bitmap_parse_region(struct region *r, const char *str,
+const char *const end, int is_user)
+{
+ long ret;
+ char c;
+
+ str = bitmap_getnum(>start, str, end, is_user);
+ if (IS_ERR(str))
+ return str;
+
+ ret = get_char(, str, is_user);
+ if (ret)
+ return (char *)ret;
+
+ if (c == 0 || c == '\n') {
+ str = end + 1;
+ goto no_end;
+ }
+
+ if (isspace(c) || c == ',')
+ goto no_end;
+
+ if (c != '-')
+ return (char *)-EINVAL;
+
+ str = bitmap_getnum(>end, str + 1, end, is_user);
+ if (IS_ERR(str))
+ return str;
+
+ ret = get_char(, str, is_user);
+ if (ret)
+ return (char *)ret;
+
+ if (c == 0 || c == '\n') {
+ str = end + 1;
+ goto no_pattern;
+ }
+
+ if (isspace(c) || c == ',')
+ goto no_pattern;
+
+ if (c != ':')
+ return (char *)-EINVAL;
+
+ str = bitmap_getnum(>off, str + 1, end, is_user);
+ if (IS_ERR(str))
+ return str;
+
+ ret = get_char(, str, is_user);
+ if (ret)
+ return (char *)ret;
+
+ if (c != '/')
+ return (char *)-EINVAL;
+
+ str = bitmap_getnum(>grlen, str + 1, end, is_user);
+
+ return str;
+
+no_end:
+ r->end = r->start;
+no_pattern:
+ r->off = r->end + 1;
+ r->grlen = r->end + 1;
+
+ return (char *)str;
+}
+
/**
* __bitmap_parselist - convert list format ASCII string to bitmap
* @buf: read nul-terminated user string from this buffer
@@ -534,113 +668,28 @@ static int bitmap_check_region(const struct region *r)
*
* Returns: 0 on success, -errno on invalid input strings. Error values:
*
- * - ``-EINVAL``: second number in range smaller than first
+ * - ``-EINVAL``: wrong region format
* - ``-EINVAL``: invalid character in string
* - ``-ERANGE``: bit number specified too large for mask
+ * - ``-EOVERFLOW``: integer overflow in the input parameters
*/
-static int __bitmap_parselist(const char *buf, unsigned int buflen,
+static int __bitmap_parselist(const char *buf, const char *const end,
int is_user, unsigned long *maskp,
int nmaskbits)
{
- unsigned int a, b, old_a, old_b;
- unsigned int group_size, used_size;
- int c, old_c, totaldigits, ndigits;
- const char __user __force *ubuf = (const char __user __force *)buf;
-
[PATCH 1/4] bitmap_parselist: don't calculate length of the input string
bitmap_parselist() calculates length of the input string before passing
it to the __bitmap_parselist(). But the end-of-line condition is checked
for every character in __bitmap_parselist() anyway. So doing it in wrapper
is a simple waste of time.
Signed-off-by: Yury Norov
---
lib/bitmap.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index eead55aa7170..ad43ba397c58 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -614,10 +614,7 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
int bitmap_parselist(const char *bp, unsigned long *maskp, int nmaskbits)
{
- char *nl = strchrnul(bp, '\n');
- int len = nl - bp;
-
- return __bitmap_parselist(bp, len, 0, maskp, nmaskbits);
+ return __bitmap_parselist(bp, UINT_MAX, 0, maskp, nmaskbits);
}
EXPORT_SYMBOL(bitmap_parselist);
--
2.17.1
[PATCH 2/4] bitmap_parselist: move part of logic to helpers
Move region checking and setting functionality of __bitmap_parselist()
to helpers.
Signed-off-by: Yury Norov
---
lib/bitmap.c | 64 +++-
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index ad43ba397c58..a60fd9723677 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -477,6 +477,42 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const
unsigned long *maskp,
}
EXPORT_SYMBOL(bitmap_print_to_pagebuf);
+/*
+ * Region 9-38:4/10 describes the following bitmap structure:
+ * 0 9 1218 38
+ * .......
+ * ^ ^ ^ ^
+ * start off grlenend
+ */
+struct region {
+ unsigned int start;
+ unsigned int off;
+ unsigned int grlen;
+ unsigned int end;
+};
+
+static int bitmap_set_region(const struct region *r,
+ unsigned long *bitmap, int nbits)
+{
+ unsigned int start;
+
+ if (r->end >= nbits)
+ return -ERANGE;
+
+ for (start = r->start; start <= r->end; start += r->grlen)
+ bitmap_set(bitmap, start, min(r->end - start + 1, r->off));
+
+ return 0;
+}
+
+static int bitmap_check_region(const struct region *r)
+{
+ if (r->start > r->end || r->grlen == 0 || r->off > r->grlen)
+ return -EINVAL;
+
+ return 0;
+}
+
/**
* __bitmap_parselist - convert list format ASCII string to bitmap
* @buf: read nul-terminated user string from this buffer
@@ -507,10 +543,11 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
int nmaskbits)
{
unsigned int a, b, old_a, old_b;
- unsigned int group_size, used_size, off;
+ unsigned int group_size, used_size;
int c, old_c, totaldigits, ndigits;
const char __user __force *ubuf = (const char __user __force *)buf;
- int at_start, in_range, in_partial_range;
+ int at_start, in_range, in_partial_range, ret;
+ struct region r;
totaldigits = c = 0;
old_a = old_b = 0;
@@ -599,15 +636,20 @@ static int __bitmap_parselist(const char *buf, unsigned
int buflen,
/* if no digit is after '-', it's wrong*/
if (at_start && in_range)
return -EINVAL;
- if (!(a <= b) || group_size == 0 || !(used_size <= group_size))
- return -EINVAL;
- if (b >= nmaskbits)
- return -ERANGE;
- while (a <= b) {
- off = min(b - a + 1, used_size);
- bitmap_set(maskp, a, off);
- a += group_size;
- }
+
+ r.start = a;
+ r.off = used_size;
+ r.grlen = group_size;
+ r.end = b;
+
+ ret = bitmap_check_region();
+ if (ret)
+ return ret;
+
+ ret = bitmap_set_region(, maskp, nmaskbits);
+ if (ret)
+ return ret;
+
} while (buflen && c == ',');
return 0;
}
--
2.17.1
Re: [PATCH 06/20] IB/ipoib: drop useless LIST_HEAD
On Sun, Dec 23, 2018 at 09:57:01AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> Commit 31c02e215700 ("IPoIB: Avoid using stale last_send counter
> when reaping AHs") removed the uses, but not the declaration.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: 31c02e215700 ("IPoIB: Avoid using stale last_send counter when reaping
> AHs")
> Signed-off-by: Julia Lawall
>
Thanks,
Reviewed-by: Leon Romanovsky
signature.asc
Description: PGP signature
Re: [PATCH 02/20] net/mlx5e: drop useless LIST_HEAD
On Sun, Dec 23, 2018 at 09:56:57AM +0100, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> These became useless in 244cd96adb5f ("net_sched: remove list_head
> from tc_action")
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: 244cd96adb5f ("net_sched: remove list_head from tc_action")
> Signed-off-by: Julia Lawall
>
Thanks,
Reviewed-by: Leon Romanovsky
signature.asc
Description: PGP signature
[PATCH 03/20] scsi: lpfc: lpfc_nvme: drop useless LIST_HEAD
Drop LIST_HEAD where the variable it declares is never used.
These were introduced with the file, but were not even used
at that time.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x;
@@
- LIST_HEAD(x);
... when != x
//
Fixes: 01649561a8b4b ("scsi: lpfc: NVME Initiator: bind to nvme_fc api")
Signed-off-by: Julia Lawall
---
Successfully 0-day tested on 151 configurations.
drivers/scsi/lpfc/lpfc_nvme.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 4c66b19e6199..2119f36213e4 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2234,9 +2234,7 @@ lpfc_new_nvme_buf(struct lpfc_vport *vport, int
num_to_alloc)
dma_addr_t pdma_phys_sgl;
uint16_t iotag, lxri = 0;
int bcnt, num_posted;
- LIST_HEAD(prep_nblist);
LIST_HEAD(post_nblist);
- LIST_HEAD(nvme_nblist);
for (bcnt = 0; bcnt < num_to_alloc; bcnt++) {
lpfc_ncmd = kzalloc(sizeof(struct lpfc_nvme_buf), GFP_KERNEL);
[PATCH 12/20] dmaengine: dw: drop useless LIST_HEAD
Drop LIST_HEAD where the variable it declares is never used.
Commit ab703f818ac3 ("dmaengine: dw: lazy allocation of dma
descriptors") removed the uses, but not the declaration.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x;
@@
- LIST_HEAD(x);
... when != x
//
Fixes: ab703f818ac3 ("dmaengine: dw: lazy allocation of dma descriptors")
Signed-off-by: Julia Lawall
---
Successfully 0-day tested on 151 configurations.
drivers/dma/dw/core.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index dc053e62f894..290d21be4d4c 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1150,7 +1150,6 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
struct dw_dma *dw = to_dw_dma(chan->device);
unsigned long flags;
- LIST_HEAD(list);
dev_dbg(chan2dev(chan), "%s: descs allocated=%u\n", __func__,
dwc->descs_allocated);
[PATCH 09/20] xfs: xfs_fsops: drop useless LIST_HEAD
Drop LIST_HEAD where the variable it declares is never used.
Commit 0410c3bb2b88 ("xfs: factor ag btree root block
initialisation") stopped using buffer_list and started using a
buffer list in an aghdr_init_data structure, but the declaration
of buffer_list was not removed.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x;
@@
- LIST_HEAD(x);
... when != x
//
Fixes: 0410c3bb2b88 ("xfs: factor ag btree root block initialisation")
Signed-off-by: Julia Lawall
---
Successfully 0-day tested on 151 configurations.
fs/xfs/xfs_fsops.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index ec2e63a7963b..f3ef70c542e1 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -40,7 +40,6 @@ xfs_growfs_data_private(
xfs_rfsblock_t new;
xfs_agnumber_t oagcount;
xfs_trans_t *tp;
- LIST_HEAD (buffer_list);
struct aghdr_init_data id = {};
nb = in->newblocks;
[PATCH 02/20] net/mlx5e: drop useless LIST_HEAD
Drop LIST_HEAD where the variable it declares is never used.
These became useless in 244cd96adb5f ("net_sched: remove list_head
from tc_action")
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x;
@@
- LIST_HEAD(x);
... when != x
//
Fixes: 244cd96adb5f ("net_sched: remove list_head from tc_action")
Signed-off-by: Julia Lawall
---
Successfully 0-day tested on 151 configurations.
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 4d6c9757afad..cae6c6d48984 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2183,7 +2183,6 @@ static bool modify_header_match_supported(struct
mlx5_flow_spec *spec,
{
const struct tc_action *a;
bool modify_ip_header;
- LIST_HEAD(actions);
u8 htype, ip_proto;
void *headers_v;
u16 ethertype;
@@ -2272,7 +2271,6 @@ static int parse_tc_nic_actions(struct mlx5e_priv *priv,
struct tcf_exts *exts,
{
struct mlx5_nic_flow_attr *attr = flow->nic_attr;
const struct tc_action *a;
- LIST_HEAD(actions);
u32 action = 0;
int err, i;
@@ -2511,7 +2509,6 @@ static int parse_tc_fdb_actions(struct mlx5e_priv *priv,
struct tcf_exts *exts,
struct mlx5e_rep_priv *rpriv = priv->ppriv;
struct ip_tunnel_info *info = NULL;
const struct tc_action *a;
- LIST_HEAD(actions);
bool encap = false;
u32 action = 0;
int err, i;
[PATCH 05/20] scsi: lpfc: lpfc_sli: drop useless LIST_HEAD
Drop LIST_HEAD where the variable it declares has never
been used.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier x;
@@
- LIST_HEAD(x);
... when != x
//
Fixes: 895427bd012ce ("scsi: lpfc: NVME Initiator: Base modifications")
Signed-off-by: Julia Lawall
---
Successfully 0-day tested on 151 configurations.
drivers/scsi/lpfc/lpfc_sli.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 30734caf77e1..13fe9d3331b9 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -3948,7 +3948,6 @@ lpfc_sli_abort_iocb_ring(struct lpfc_hba *phba, struct
lpfc_sli_ring *pring)
void
lpfc_sli_abort_wqe_ring(struct lpfc_hba *phba, struct lpfc_sli_ring *pring)
{
- LIST_HEAD(completions);
struct lpfc_iocbq *iocb, *next_iocb;
if (pring->ringno == LPFC_ELS_RING)
