Re: [PATCH 2/2] selftests/pstore: add pstore test scripts going with reboot
Hello,
>> +prlog "Causing kernel crash ..."
>> +
>> +# enable all functions triggered by sysrq
>> +echo 1 > /proc/sys/kernel/sysrq
>> +# setting to reboot in 3 seconds after panic
>> +echo 3 > /proc/sys/kernel/panic
>> +# setting to cause panic when oops occurs
>> +echo 1 > /proc/sys/kernel/panic_on_oops
>> +
>> +# create a file as reboot flag
>> +touch $REBOOT_FILE
>> +sync
>> +
>> +# cause crash
>> +echo c > /proc/sysrq-trigger
>
> Do you need to stop kdump service before the sysrq?
Yes, I should check /sys/kernel/kexec_crash_loaded. If the value is
1, this script should try to unload kexec kernel.
> Or, does it cover oops and kdump case?
No, not yet. I think we should support oops case at first.
Best regards,
Hiraku Toyooka
阿口誠司 / AGUCHI，SEIJI wrote:
+prlog "Causing kernel crash ..."
+
+# enable all functions triggered by sysrq
+echo 1 > /proc/sys/kernel/sysrq
+# setting to reboot in 3 seconds after panic
+echo 3 > /proc/sys/kernel/panic
+# setting to cause panic when oops occurs
+echo 1 > /proc/sys/kernel/panic_on_oops
+
+# create a file as reboot flag
+touch $REBOOT_FILE
+sync
+
+# cause crash
+echo c > /proc/sysrq-trigger
Do you need to stop kdump service before the sysrq?
Or, does it cover oops and kdump case?
Seiji
-Original Message-
From: 豊岡拓 / Toyooka，Hiraku
Sent: Tuesday, September 15, 2015 11:42 AM
To: Kees Cook
Cc: LKML; Tony Luck; Linux API; Anton Vorontsov; Shuah Khan; Mark Salyzyn;
Colin Cross; 阿口誠司 / AGUCHI，SEIJI
Subject: Re: [PATCH 2/2] selftests/pstore: add pstore test scripts going with
reboot
Hello Kees,
>> +run_crash:
>> + @sh pstore_crash_test || echo "pstore_crash_test: [FAIL]"
>
> This is probably better written to exit 1 on failure, otherwise it
> just _says_ it fails. (Though lots of selftests in the tree already
> have this problem, it's best to avoid the pattern for new stuff.)
> Maybe something like:
>
> @sh pstore_crash_test || { echo "pstore_crash_test: [FAIL]";
exit 1; }
OK. I'll add the "exit 1".
>> +prlog -n "Checking dmesg files exist in pstore filesystem ... "
>> +if [ -e dmesg-${backend}-0 ]; then
>> +prlog "ok"
>> +for f in `ls dmesg-${backend}-*`; do
>> + prlog -e "\t${f}"
>> +done
>> +else
>> +prlog "FAIL"
>> +rc=1
>> +fi
>
> This test pattern is repeated a lot. Maybe better to create a helper
> function instead? It could make the tests much more readable.
Yes, I should make a helper function in v2.
Best regards,
Hiraku Toyooka
--
Hiraku Toyooka
Systems Productivity Research Dept. / Linux Technology Center
Center for Technology Innovation - Systems Engineering, Hitachi Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] selftests/pstore: add pstore test script for pre-reboot
Hello,
> It may be good if you can log "/sys/module/pstore/parameters/backend/"
> or /proc/cmdline in failure case.
>
> It makes debug easy.
OK, I'll have the script log the information in v2.
Best regards,
Hiraku Toyooka
阿口誠司 / AGUCHI，SEIJI wrote:
Hi,
+prlog -n "Checking pstore backend is registered ... "
+be_msg=`dmesg | grep "pstore: Registered [a-zA-Z0-9]\+ as persistent store
backend$"`
+if [ $? -eq 0 ]; then
+backend=`echo ${be_msg} | sed -e 's/^.*Registered\ \([a-zA-z0-9-]\+\)\
as.*$/\1/g'`
+prlog "ok"
+else
+prlog "FAIL"
+exit 1
It may be good if you can log "/sys/module/pstore/parameters/backend/"
or /proc/cmdline in failure case.
It makes debug easy.
Seiji
+fi
-Original Message-
From: 豊岡拓 / Toyooka，Hiraku
Sent: Tuesday, September 15, 2015 11:31 AM
To: Kees Cook
Cc: LKML; Tony Luck; Linux API; Anton Vorontsov; Shuah Khan; Mark Salyzyn;
Colin Cross; 阿口誠司 / AGUCHI，SEIJI
Subject: Re: [PATCH 1/2] selftests/pstore: add pstore test script for pre-reboot
Hello, Kees,
Thank you for your advise.
>> +be_msg=`dmesg | grep "pstore: Registered [a-zA-Z0-9]\+ as
persistent store backend$"`
...
> This seems unstable if the system hasn't booted recently or if stuff
> is spamming dmesg. What about examining /sys/module/pstore instead?
OK, I'll update in that way.
Best regards,
Hiraku Toyooka
Kees Cook wrote:
On Tue, Sep 8, 2015 at 4:06 AM, Hiraku Toyooka
wrote:
The pstore_tests script includes test cases which check pstore's
behavior before crash (and reboot).
The test cases are currently following.
- Check pstore backend is registered
- Check pstore console is registered
- Check /dev/pmsg0 exists
- Write string to /dev/pmsg0
Example usage is following.
make: Entering directory '/home/root/selftests/pstore'
=== Pstore unit tests (pstore_tests)===
Checking pstore backend is registered ... ok
Checking pstore console is registered ... ok
Checking /dev/pmsg0 exists ... ok
Writing TEST_STRING to /dev/pmsg0 ... ok
selftests: pstore_tests [PASS]
=== Pstore unit tests (pstore_post_reboot_tests)===
Checking pstore backend is registered ... ok
pstore_crash_test has not been executed yet. we skip further tests.
selftests: pstore_post_reboot_tests [PASS]
make: Leaving directory '/home/root/selftests/pstore'
We can also see test logs later.
Signed-off-by: Hiraku Toyooka
Cc: Shuah Khan
Cc: Tony Luck
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Kees Cook
Cc: Mark Salyzyn
Cc: Seiji Aguchi
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
tools/testing/selftests/Makefile|1 +
tools/testing/selftests/pstore/Makefile | 12 +++
tools/testing/selftests/pstore/common_tests | 45
+++
tools/testing/selftests/pstore/pstore_tests | 42 +
4 files changed, 100 insertions(+)
create mode 100644 tools/testing/selftests/pstore/Makefile
create mode 100755 tools/testing/selftests/pstore/common_tests
create mode 100755 tools/testing/selftests/pstore/pstore_tests
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 24ae9e8..b58c72e 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -12,6 +12,7 @@ TARGETS += mount
TARGETS += mqueue
TARGETS += net
TARGETS += powerpc
+TARGETS += pstore
TARGETS += ptrace
TARGETS += seccomp
TARGETS += size
diff --git a/tools/testing/selftests/pstore/Makefile
b/tools/testing/selftests/pstore/Makefile
new file mode 100644
index 000..40b887d
--- /dev/null
+++ b/tools/testing/selftests/pstore/Makefile
@@ -0,0 +1,12 @@
+# Makefile for pstore selftests.
+# Expects pstore backend is registered.
+
+all:
+
+TEST_PROGS := pstore_tests
+TEST_FILES := common_tests
+
+include ../lib.mk
+
+clean:
+ rm -rf logs/*
diff --git a/tools/testing/selftests/pstore/common_tests
b/tools/testing/selftests/pstore/common_tests
new file mode 100755
index 000..98611c5
--- /dev/null
+++ b/tools/testing/selftests/pstore/common_tests
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+# common_tests - Shell script commonly used by pstore test scripts
+#
+# Copyright (C) Hitachi Ltd., 2015
+# Written by Hiraku Toyooka
+#
+# Released under the terms of the GPL v2.
+
+# Utilities
+errexit() { # message
+ echo "Error: $1" 1>&2
+ exit 1
+}
+
+absdir() { # file_path
+ (cd `dirname $1`; pwd)
+}
+
+# Parameters
+TOP_DIR=`absdir $0`
+LOG_DIR=$TOP_DIR/logs/`date +%Y%m%d-%H%M%S`/
+TEST_STRING="Testing pstore"
+
+# Preparing logs
+LOG_FILE=$LOG_DIR/`basename $0`.log
+mkdir -p $LOG_DIR || errexit "Failed to make a log directory: $LOG_DIR"
+date > $LOG_FILE
+prlog() { # messages
+ /bin/echo "$@" | tee -a $LOG_FILE
+}
+prlog "=== Pstore unit tests (`basename $0`)==="
+
+# Starting tests
+rc=0
+
+prlog -n "Checking pstore backend is registered ... "
+be_msg=`dmesg | grep "pstore: Registered [a-zA-Z0-9]\+ as persistent store
backend$"`
+if [ $? -eq 0 ]; then
+backend=`echo ${be_msg} | sed -e
turn panic into data corruption, dangerous patch was Re: [PATCH] [v3] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map
On Wed 2015-09-02 20:06:28, Chen Yu wrote:
> On some platforms, there is occasional panic triggered when trying to
> resume from hibernation, a typical panic looks like:
>
> BUG: unable to handle kernel paging request at 880085894000
> IP: [] load_image_lzo+0x8c2/0xe70
>
> This is because e820 map has been changed by BIOS before/after
> hibernation, and one of the page frames from first kernel
> is right located in second kernel's unmapped region, so panic
> comes out when accessing unmapped kernel address.
> After this patch applied, the panic will be replaced with the warning:
and with data corruption.
> PM: Loading and decompressing image data (96092 pages)...
> PM: Image loading progress: 0%
> PM: Image loading progress: 10%
> PM: Image loading progress: 20%
> PM: Image loading progress: 30%
> PM: Image loading progress: 40%
> PM: 0x849dd000 to restored not in valid memory region
>
> Signed-off-by: Chen Yu
> ---
>
> v3:
> - Adjust the logic to exclude the end_pfn boundary in pfn_mapped
>when invoking mark_valid_pages, because the end_pfn is not
>a mapped page frame, we should not regard it as a valid page.
>
>Move the sanity check of valid pages to a early stage in resuming
>process(moved to mark_unsafe_pages), in this way, we can avoid
>unnecessarily accessing these invalid pages in later stage(yes,
>move to the original position Joey once introduced in:
>Commit 84c91b7ae07c ("PM / hibernate: avoid unsafe pages in e820
>reserved regions")
>
>With v3 patch applied, I did 30 cycles on my problematic platform,
>no panic triggered anymore(50% reproducible before patched, by
>plugging/unplugging memory peripheral during hibernation), and it
>just warns of invalid pages.
"Just warns of invalid pages". Do you want to say that you "just cause
data corruption"?
If you don't have enough memory, YOU DON'T RESTORE. Disks were synced,
so not restoring is safe. Running with memory corruption is NOT.
> + if (!swsusp_page_is_valid(pfn_to_page(pfn))) {
> + pr_err(
> + "PM: %#010llx to restored not in valid memory
> region\n",
> + (unsigned long long) pfn << PAGE_SHIFT);
And you'd need to fix english here in any case.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] scsi: ufs-exynos: add UFS host support for Exynos SoCs
HI Amit,
On 08/26/2015 12:12 PM, amit daniel kachhap wrote:
On Fri, Aug 21, 2015 at 2:58 PM, Alim Akhtar wrote:
From: Seungwon Jeon
This patch introduces Exynos UFS host controller driver,
which mainly handles vendor-specific operations including
link startup, power mode change and hibernation/unhibernation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
.../devicetree/bindings/ufs/ufs-exynos.txt | 92 ++
drivers/scsi/ufs/Kconfig | 12 +
drivers/scsi/ufs/Makefile |1 +
drivers/scsi/ufs/ufs-exynos-hw.c | 147 +++
drivers/scsi/ufs/ufs-exynos-hw.h | 43 +
drivers/scsi/ufs/ufs-exynos.c | 1175
drivers/scsi/ufs/ufs-exynos.h | 463
drivers/scsi/ufs/ufshci.h | 26 +-
drivers/scsi/ufs/unipro.h | 47 +
9 files changed, 2005 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
create mode 100644 drivers/scsi/ufs/ufs-exynos.c
create mode 100644 drivers/scsi/ufs/ufs-exynos.h
diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
new file mode 100644
index 000..1a6184d
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
@@ -0,0 +1,92 @@
+* Exynos Universal Flash Storage (UFS) Host Controller
+
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible list, contains "samsung,exynos7-ufs"
+- interrupts:
+- reg :
+
+Optional properties:
+- vdd-hba-supply: phandle to UFS host controller supply regulator node
+- vcc-supply: phandle to VCC supply regulator node
+- vccq-supply : phandle to VCCQ supply regulator node
+- vccq2-supply : phandle to VCCQ2 supply regulator node
+- vcc-supply-1p8: For embedded UFS devices, valid VCC range is
1.7-1.95V
+ or 2.7-3.6V. This boolean property when set,
specifies
+ to use low voltage range of 1.7-1.95V. Note for
external
+ UFS cards this property is invalid and valid VCC
range is
+ always 2.7-3.6V.
+- vcc-max-microamp : specifies max. load that can be drawn from vcc supply
+- vccq-max-microamp : specifies max. load that can be drawn from vccq
supply
+- vccq2-max-microamp: specifies max. load that can be drawn from vccq2
supply
+- -fixed-regulator : boolean property specifying that -supply is a
fixed regulator
+
+- clocks: List of phandle and clock specifier pairs
+- clock-names : List of clock input name strings sorted in the same
+ order as the clocks property.
+- freq-table-hz: Array of operating frequencies
stored in the same
+ order as the clocks property. If this property is not
+ defined or a value in the array is "0" then it is
assumed
+ that the frequency is set by the parent clock or a
+ fixed rate clock source.
+- pclk-freq-avail-range : specifies available frequency range(min/max) for APB
clock
+- ufs,pwr-attr-mode : specifies mode value for power mode change
+- ufs,pwr-attr-lane : specifies lane count value for power mode change
+- ufs,pwr-attr-gear : specifies gear count value for power mode change
+- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change
+- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values
+
+- ufs,pwr-remote-l2-timer : specifies array of remote UNIPR L2 timer values
s/UNIPR/UNIPRO
ok
+
+- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY
I suppose this field is bool type. This can be mentioned here.
+- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY
+- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate
time of MPHY
+- ufs-pa-granularity : specifies Granularity for PA_TActivate and
PA_Hibern8Time
+- ufs-pa-tacctivate : specifies time wake-up remote M-RX
+- ufs-pa-hibern8time : specifies minimum time to wait in HIBERN8 state
+
+Note: If above properties are not defined it can be assumed that the supply
+regulators or clocks are always on.
+
+Example:
+ ufshc@0x1557 {
+ compatible = "samsung,exynos7-ufs";
+ reg = <0xfc598000 0x800>;
+ reg = <0x1557 0x100>,
+ <0x15570100 0x100>,
+ <0x15571000 0x200>,
+
[lkp] [Btrfs] b659ef0277: +159.7% fileio.requests_per_sec
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit b659ef027792219b590d67a2baf1643a93727d29 ("Btrfs: avoid syncing log in
the fast fsync path when not necessary")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/period/nr_threads/disk/fs/size/filenum/rwmode/iomode:
lkp-sb02/fileio/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/600s/100%/1HDD/btrfs/64G/1024f/rndwr/sync
commit:
1ab818b137e198e4d06e987a4b089411f2e39d40
b659ef027792219b590d67a2baf1643a93727d29
1ab818b137e198e4 b659ef027792219b590d67a2ba
--
%stddev %change %stddev
\ |\
156.81 ±171% -99.2% 1.20 ± 14% fileio.request_latency_max_ms
17.03 ± 0%+159.7% 44.24 ± 0% fileio.requests_per_sec
2373960 ± 0% +6.7%2533688 ± 0% fileio.time.file_system_outputs
161019 ± 0% -14.3% 137992 ± 0%
fileio.time.voluntary_context_switches
9810964 ± 2% -17.9%8052196 ± 1% cpuidle.C3-SNB.time
161019 ± 0% -14.3% 137992 ± 0% time.voluntary_context_switches
3568 ± 0% -2.4% 3484 ± 0% vmstat.io.bo
60476 ± 0% +18.1% 71428 ± 0% proc-vmstat.nr_active_file
507.75 ± 0% +86.4% 946.25 ± 0% proc-vmstat.nr_dirty
10809 ± 0% +15.6% 12497 ± 0% proc-vmstat.nr_slab_reclaimable
52238 ± 0% +13.4% 59232 ± 0% proc-vmstat.pgactivate
10189 ± 8% -9.9% 9180 ± 8%
sched_debug.cfs_rq[0]:/.min_vruntime
1.75 ±4164% +6385.7% 113.50 ± 16%
sched_debug.cpu#2.nr_uninterruptible
14748 ± 3% -7.2% 13685 ± 2% sched_debug.cpu#2.ttwu_local
141.25 ± 47% -83.9% 22.75 ±169%
sched_debug.cpu#3.nr_uninterruptible
50725 ± 0% -9.8% 45774 ± 0% softirqs.BLOCK
43962 ± 1% -13.9% 37864 ± 1% softirqs.RCU
32134 ± 1% -8.8% 29295 ± 1% softirqs.SCHED
62715 ± 1% -9.9% 56488 ± 0% softirqs.TIMER
50.00 ± 0% +2.0% 51.00 ± 0% turbostat.Avg_MHz
0.41 ± 2% -14.5% 0.35 ± 2% turbostat.CPU%c3
2.69 ± 0% -9.9% 2.42 ± 0% turbostat.Pkg%pc2
1.02 ± 4% -22.9% 0.78 ± 4% turbostat.Pkg%pc3
260823 ± 0% +16.8% 304593 ± 0% meminfo.Active
241907 ± 0% +18.1% 285712 ± 0% meminfo.Active(file)
2033 ± 0% +86.2% 3784 ± 0% meminfo.Dirty
43239 ± 0% +15.6% 49990 ± 0% meminfo.SReclaimable
61606 ± 0% +11.0% 68373 ± 0% meminfo.Slab
1571 ± 5% +16.0% 1823 ± 8%
slabinfo.btrfs_delayed_data_ref.active_objs
1577 ± 5% +16.0% 1830 ± 8%
slabinfo.btrfs_delayed_data_ref.num_objs
1256 ± 5% -13.3% 1089 ± 8%
slabinfo.btrfs_delayed_ref_head.active_objs
1261 ± 5% -13.3% 1093 ± 8%
slabinfo.btrfs_delayed_ref_head.num_objs
767.25 ± 2% +14.7% 880.25 ± 4%
slabinfo.btrfs_delayed_tree_ref.active_objs
767.25 ± 2% +14.7% 880.25 ± 4%
slabinfo.btrfs_delayed_tree_ref.num_objs
2933 ± 3% -29.6% 2066 ± 0%
slabinfo.btrfs_extent_buffer.active_objs
2944 ± 2% -29.4% 2079 ± 0%
slabinfo.btrfs_extent_buffer.num_objs
5699 ± 0%+129.2% 13066 ± 0%
slabinfo.btrfs_extent_state.active_objs
111.50 ± 1%+129.6% 256.00 ± 0%
slabinfo.btrfs_extent_state.active_slabs
5699 ± 0%+129.4% 13078 ± 0%
slabinfo.btrfs_extent_state.num_objs
111.50 ± 1%+129.6% 256.00 ± 0%
slabinfo.btrfs_extent_state.num_slabs
351.00 ± 2%+103.5% 714.25 ± 0%
slabinfo.btrfs_ordered_extent.active_objs
376.75 ± 2% +91.1% 720.00 ± 0%
slabinfo.btrfs_ordered_extent.num_objs
12062 ± 0%+122.3% 26821 ± 0% slabinfo.btrfs_path.active_objs
430.50 ± 0%+122.4% 957.50 ± 0% slabinfo.btrfs_path.active_slabs
12062 ± 0%+122.3% 26821 ± 0% slabinfo.btrfs_path.num_objs
430.50 ± 0%+122.4% 957.50 ± 0% slabinfo.btrfs_path.num_slabs
407.25 ± 0% +80.4% 734.50 ± 4%
slabinfo.ext4_extent_status.active_objs
407.25 ± 0% +80.4% 734.50 ± 4%
slabinfo.ext4_extent_status.num_objs
19541 ± 0% +36.8% 26730 ± 0%
slabinfo.radix_tree_node.active_objs
697.50 ± 0% +36.8% 954.25 ± 0%
slabinfo.radix_tree_node.active_slabs
19541 ± 0% +36.8% 26730 ± 0% slabinfo.radix_tree_node.num_objs
697.50 ± 0% +36.8% 954.25 ± 0% slabinfo.radix_tree_node.num_slabs
158807 ± 2%+131.0% 366899 ± 3%
Re: [PATCH] [v2] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map
Hi! > PM: Image mismatch: memory size > > This is also because BIOS provides different e820 memory map before/after > hibernation, and linux regards it as invalid process and refuses to > resume, in order to protect against data corruption. However, > this check might be too strict, consider the following scenario: Well... yes, the check is strict, but why is BIOS doing that? Can you fix it instead? > The hibernating system has a smaller memory capacity than > the resuming system, and the former memory region is a subset of the > latter, it should be allowed to resume. Here is a case for this > situation: > > before hibernation: > > BIOS-e820: [mem 0x2020-0x77517fff] usable > BIOS-e820: [mem 0x77518000-0x77567fff] reserved > Memory: 3871356K/4058428K available (7595K kernel code, 1202K rwdata, > 3492K rodata, 1400K init, 1308K bss, 187072K reserved, 0K cma-reserved) > > after hibernation: > BIOS-e820: [mem 0x2020-0x7753] usable > BIOS-e820: [mem 0x7754-0x77567fff] reserved > Memory: 3871516K/4058588K available (7595K kernel code, 1202K rwdata, > 3492K rodata, 1400K init, 1308K bss, 187072K reserved, 0K cma-reserved) > > According to above data, the number of present_pages has increased by > 40(thus 160K), linux will terminate the resuming process. But since > [0x2020-0x77517fff] is a subset of > [0x2020-0x7753], we should let system > resume. Ok, complex, but will work. But what happens in the opposite case? On the next boot, bios gets you 160K less Can you do echo powerdown > /sys/power/disk to work around this? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Ensure proper suspend/resume ordering
On 17 September 2015 at 02:27, Rafael J. Wysocki wrote: > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >> >> It would also help if your patch checked to see if the device has any >> children, and avoided moving it to the end of the list if it does. In >> fact, that might be sufficient to avoid almost all problems. > > I agree. > > In any case if a device that already has children is about to be probed, > this is sort of a corner case anyway and should be handled as such. Just wanted to mention that it's very common in platforms that make use of DT to have some devices registered before their parents have probed. If I grep for DTS with simple-bus and simple-mfd I get 802 matches. Regards, Tomeu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686
Am 17.09.2015 um 01:52 schrieb Josh Boyer: > > Did this actually happen? I don't see either fix in Linus' tree yet, > the merge window is closed, and the bug happens on 4.1 and 4.2 stable > kernels.. > > josh > Seems not yet. I don't see it neither in 4.3-rc1. Seems 4.3 will have the same issues then ... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v4 4/4] arm: fix a migrating irq bug when hotplug cpu
When cpu is disabled, all irqs will be migratged to another cpu.
In some cases, a new affinity is different, it needed to be coppied
to irq's affinity. But if the type of irq is LPI, it's affinity will
not be coppied because of irq_set_affinity's return value. Fix it by
using irq_do_set_affinity.
And migrating interrupts is a core code matter, so use the generic
function move_irqs() to migrate interrupts in kernel/irq/migration.c.
Cc: Jiang Liu
Cc: Thomas Gleixner
Cc: Marc Zyngier
Cc: Mark Rutland
Cc: Will Deacon
Cc: Russell King - ARM Linux
Cc: Hanjun Guo
Signed-off-by: Yang Yingliang
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/irq.h | 1 -
arch/arm/kernel/irq.c | 62 --
arch/arm/kernel/smp.c | 2 +-
4 files changed, 2 insertions(+), 64 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72ad724..bffba78 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1492,6 +1492,7 @@ config NR_CPUS
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
+ select GENERIC_IRQ_MIGRATION
help
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu.
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index be1d07d..882bf98 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -24,7 +24,6 @@
#ifndef __ASSEMBLY__
struct irqaction;
struct pt_regs;
-extern void migrate_irqs(void);
extern void asm_do_IRQ(unsigned int, struct pt_regs *);
void handle_IRQ(unsigned int, struct pt_regs *);
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 5ff4826..78abea8 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -136,64 +135,3 @@ int __init arch_probe_nr_irqs(void)
return nr_irqs;
}
#endif
-
-#ifdef CONFIG_HOTPLUG_CPU
-static bool migrate_one_irq(struct irq_desc *desc)
-{
- struct irq_data *d = irq_desc_get_irq_data(desc);
- const struct cpumask *affinity = irq_data_get_affinity_mask(d);
- struct irq_chip *c;
- bool ret = false;
-
- /*
-* If this is a per-CPU interrupt, or the affinity does not
-* include this CPU, then we have nothing to do.
-*/
- if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(),
affinity))
- return false;
-
- if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
- affinity = cpu_online_mask;
- ret = true;
- }
-
- c = irq_data_get_irq_chip(d);
- if (!c->irq_set_affinity)
- pr_debug("IRQ%u: unable to set affinity\n", d->irq);
- else if (c->irq_set_affinity(d, affinity, false) == IRQ_SET_MASK_OK &&
ret)
- cpumask_copy(irq_data_get_affinity_mask(d), affinity);
-
- return ret;
-}
-
-/*
- * The current CPU has been marked offline. Migrate IRQs off this CPU.
- * If the affinity settings do not allow other CPUs, force them onto any
- * available CPU.
- *
- * Note: we must iterate over all IRQs, whether they have an attached
- * action structure or not, as we need to get chained interrupts too.
- */
-void migrate_irqs(void)
-{
- unsigned int i;
- struct irq_desc *desc;
- unsigned long flags;
-
- local_irq_save(flags);
-
- for_each_irq_desc(i, desc) {
- bool affinity_broken;
-
- raw_spin_lock(>lock);
- affinity_broken = migrate_one_irq(desc);
- raw_spin_unlock(>lock);
-
- if (affinity_broken)
- pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
- i, smp_processor_id());
- }
-
- local_irq_restore(flags);
-}
-#endif /* CONFIG_HOTPLUG_CPU */
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 48185a7..262ead7 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -218,7 +218,7 @@ int __cpu_disable(void)
/*
* OK - migrate IRQs away from this CPU
*/
- migrate_irqs();
+ move_irqs();
/*
* Flush user cache and TLB mappings, and then remove this CPU
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
DEFINE_IDA causing memory leaks? (was Re: [PATCH 1/2] virtio: fix memory leak of virtio ida cache layers)
On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote:
> The virtio core uses a static ida named virtio_index_ida for
> assigning index numbers to virtio devices during registration.
> The ida core may allocate some internal idr cache layers and
> an ida bitmap upon any ida allocation, and all these layers are
> truely freed only upon the ida destruction. The virtio_index_ida
> is not destroyed at present, leading to a memory leak when using
> the virtio core as a module and atleast one virtio device is
> registered and unregistered.
>
> Fix this by invoking ida_destroy() in the virtio core module
> exit.
>
> Cc: "Michael S. Tsirkin"
> Signed-off-by: Suman Anna
Interesting.
Will the same apply to e.g. sd_index_ida in drivers/scsi/sd.c
or iscsi_sess_ida in drivers/scsi/scsi_transport_iscsi.c?
If no, why not?
One doesn't generally expect to have to free global variables.
Maybe we should forbid DEFINE_IDA in modules?
James, could you comment on this please?
> ---
> drivers/virtio/virtio.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index b1877d73fa56..7062bb0975a5 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -412,6 +412,7 @@ static int virtio_init(void)
> static void __exit virtio_exit(void)
> {
> bus_unregister(_bus);
> + ida_destroy(_index_ida);
> }
> core_initcall(virtio_init);
> module_exit(virtio_exit);
> --
> 2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend
On Thu 2015-08-27 11:18:27, Chen Yu wrote:
> A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
> that, after resumed from S3, CPU is running at a low speed.
> After investigation, it is found that, BIOS has modified the value
> of THERM_CONTROL register during S3, and changes it from 0 to 0x10,
> since value of 0x10 means CPU can only get 25% of the Duty Cycle,
> this triggers the problem.
>
> Here is a simple scenario to reproduce the issue:
> 1.Boot up the system
> 2.Get MSR with address 0x19a, it should be 0
> 3.Put the system into sleep, then wake it up
> 4.Get MSR with address 0x19a, it should be 0(actually it shows 0x10)
>
> Although this is a BIOS issue, it would be more robust for linux to deal
> with this situation. This patch fixes this issue by introducing a framework
> to save/restore specified MSR registers(THERM_CONTROL in this case)
> for suspend/resume.
>
> When user encounters a problematic platform and needs to protect the
> MSRs during suspending, he can simply add a quirk entry in
> msr_save_dmi_table, and customizes MSR registers inside the quirk
> callback, for example:
>
> u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
>
> and the quirk mechanism ensures that, once resumed from suspended,
> the MSRs indicated by these IDs will be restored to their original values
> before suspended.
>
> Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
> common code path. And because the MSRs specified by the user might not
> be available or readable in any situation, we use rdmsrl_safe to safely
> save these MSRs.
>
> Tested-by: Marcin Kaszewski
> Signed-off-by: Chen Yu
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v4 2/4] genirq: add move_irqs() for cpu hotplug
Add move_irqs() into kernel/irq/migration.c.
So we can use it to migrate interrupts, when
cpu is offline.
Cc: Jiang Liu
Cc: Thomas Gleixner
Cc: Marc Zyngier
Cc: Mark Rutland
Cc: Will Deacon
Cc: Russell King - ARM Linux
Cc: Hanjun Guo
Signed-off-by: Yang Yingliang
---
include/linux/irq.h| 4 +++
kernel/irq/migration.c | 66 ++
2 files changed, 70 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 6f8b340..64e3a02 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -446,6 +446,10 @@ static inline void irq_move_irq(struct irq_data *data) { }
static inline void irq_move_masked_irq(struct irq_data *data) { }
#endif
+#if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_IRQ_MIGRATION) &&
defined(CONFIG_HOTPLUG_CPU)
+void move_irqs(void);
+#endif
+
extern int no_irq_affinity;
#ifdef CONFIG_HARDIRQS_SW_RESEND
diff --git a/kernel/irq/migration.c b/kernel/irq/migration.c
index 1ff2b77..75bff60 100644
--- a/kernel/irq/migration.c
+++ b/kernel/irq/migration.c
@@ -1,6 +1,7 @@
#include
#include
+#include
#include "internals.h"
@@ -79,3 +80,68 @@ void irq_move_irq(struct irq_data *idata)
idata->chip->irq_unmask(idata);
}
#endif
+
+#ifdef CONFIG_HOTPLUG_CPU
+static bool migrate_one_irq(struct irq_desc *desc)
+{
+ struct irq_data *d = irq_desc_get_irq_data(desc);
+ const struct cpumask *affinity = d->affinity;
+ struct irq_chip *c;
+ bool ret = false;
+
+ /*
+* If this is a per-CPU interrupt, or the affinity does not
+* include this CPU, then we have nothing to do.
+*/
+ if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(),
affinity))
+ return false;
+
+ if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+ affinity = cpu_online_mask;
+ ret = true;
+ }
+
+ c = irq_data_get_irq_chip(d);
+ if (!c->irq_set_affinity) {
+ pr_warn_ratelimited("IRQ%u: unable to set affinity\n", d->irq);
+ } else {
+ int r = irq_do_set_affinity(d, affinity, false);
+ if (r)
+ pr_warn_ratelimited("IRQ%u: set affinity
failed(%d).\n", d->irq, r);
+ }
+
+ return ret;
+}
+
+/*
+ * The current CPU has been marked offline. Migrate IRQs off this CPU.
+ * If the affinity settings do not allow other CPUs, force them onto any
+ * available CPU.
+ *
+ * Note: we must iterate over all IRQs, whether they have an attached
+ * action structure or not, as we need to get chained interrupts too.
+ */
+void move_irqs(void)
+{
+ unsigned int irq;
+ struct irq_desc *desc;
+ unsigned long flags;
+
+ local_irq_save(flags);
+
+ for_each_active_irq(irq) {
+ bool affinity_broken;
+
+ desc = irq_to_desc(irq);
+ raw_spin_lock(>lock);
+ affinity_broken = migrate_one_irq(desc);
+ raw_spin_unlock(>lock);
+
+ if (affinity_broken)
+ pr_warn_ratelimited("IRQ%u no longer affine to CPU%u\n",
+ irq, smp_processor_id());
+ }
+
+ local_irq_restore(flags);
+}
+#endif /* CONFIG_HOTPLUG_CPU */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 03/16] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters
On Thu, Sep 17, 2015 at 01:06:33AM -0400, Raphaël Beamonte wrote:
> 2015-09-17 0:57 GMT-04:00 Greg Kroah-Hartman :
>
> >> @@ -1748,8 +1755,9 @@ static short rtl8192_usb_initendpoints(struct
> >> net_device *dev)
> >> oldaddr = priv->oldaddr;
> >> align = ((long)oldaddr) & 3;
> >> if (align) {
> >> - newaddr = oldaddr + 4 - align;
> >> - priv->rx_urb[16]->transfer_buffer_length = 16 - 4 +
> >> align;
> >> + align = 4 - align;
> >> + newaddr = oldaddr + align;
> >> + priv->rx_urb[16]->transfer_buffer_length = 16 -
> >> align;
> >
> > At a quick glance, this conversion looks wrong...
>
> What is wrong with it?
>
> oldaddr + 4 - align;
> can also be read:
> oldaddr + (4 - align);
>
> as well as
> 16 - 4 + align;
> can also be read
> 16 - (4 - align);
> as when we remove the parenthesis, the - sign invert the parenthesis
> elements signs.
>
> Calculating (4 - align) previously thus preserve the logic here!
Ugh, it's been a long day, yeah, ok, this is the same, you are right.
But step back please, what exactly is this trying to do? I think it's a
round_up type function, perhaps that should be what we do instead (the
kernel has such functions already.)
> > And it's not what your changelog text said you were doing :(
>
> It's true that I didn't add a new temporary variable here but instead
> re-used one that is not used after, but I thought it went in the same
> idea as the rest of this patch. Should I separate that as another
> patch?
It might be the same "idea", but it's not what you did, so don't try to
sneak it in.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: omapdss: Division by zero in kernel
> > if (image->depth == 1) {
> > if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
> > p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> > fgcolor =
> > ((u32*)(p->pseudo_palette))[image->fg_color];
> > bgcolor =
> > ((u32*)(p->pseudo_palette))[image->bg_color];
> > } else {
> > fgcolor = image->fg_color;
> > bgcolor = image->bg_color;
> > }
> >
> > if (32 % bpp == 0 && !start_index && !pitch_index &&
> > ((width & (32/bpp-1)) == 0) &&
> > bpp >= 8 && bpp <= 32)
> > fast_imageblit(image, p, dst1, fgcolor, bgcolor);
> > else
> > slow_imageblit(image, p, dst1, fgcolor, bgcolor,
> > start_index, pitch_index);
> > } else
> > color_imageblit(image, p, dst1, start_index, pitch_i
> >
> >
> > Notice that bpp is not checked for zero, and thus bpp==0 is totally
> > feasible? resulting in 32/bpp crashing the kernel?
> >
>
> Hm... this could really be a problem! But how to patch it? Which branch
> should be called (fast_ or slow_ function) if bpp is zero?
>
> And is there some way to force kernel to dump backtrace into dmesg when
> division by zero occur?
You can do WARN_ON(bpp==1) ... and should probably return in that
case.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] regmap: irq: add support for chips who have separate unmask registers
From: Guo Zeng
Some chips have separate unmask registers from mask registers for
some consideration of concurrency SMP write performance. And this
patch adds a flag for it.
An user will be CSR SiRFSoC ARM chips.
Signed-off-by: Guo Zeng
Signed-off-by: Barry Song
---
drivers/base/regmap/regmap-irq.c | 28 ++--
include/linux/regmap.h | 3 +++
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 38d1f72..1821c3b 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -63,6 +63,7 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
struct regmap *map = d->map;
int i, ret;
u32 reg;
+ u32 unmask_offset;
if (d->chip->runtime_pm) {
ret = pm_runtime_get_sync(map->dev);
@@ -82,7 +83,22 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
if (d->chip->mask_invert)
ret = regmap_update_bits(d->map, reg,
d->mask_buf_def[i], ~d->mask_buf[i]);
- else
+ else if (d->chip->unmask_base) {
+ /* set mask with mask_base register */
+ ret = regmap_update_bits(d->map, reg,
+ d->mask_buf_def[i], ~d->mask_buf[i]);
+ if (ret < 0)
+ dev_err(d->map->dev,
+ "Failed to sync unmasks in %x\n",
+ reg);
+ unmask_offset = d->chip->unmask_base -
+ d->chip->mask_base;
+ /* clear mask with unmask_base register */
+ ret = regmap_update_bits(d->map,
+ reg + unmask_offset,
+ d->mask_buf_def[i],
+ d->mask_buf[i]);
+ } else
ret = regmap_update_bits(d->map, reg,
d->mask_buf_def[i], d->mask_buf[i]);
if (ret != 0)
@@ -339,6 +355,7 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
int i;
int ret = -ENOMEM;
u32 reg;
+ u32 unmask_offset;
if (chip->num_regs <= 0)
return -EINVAL;
@@ -420,7 +437,14 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
if (chip->mask_invert)
ret = regmap_update_bits(map, reg,
d->mask_buf[i], ~d->mask_buf[i]);
- else
+ else if (d->chip->unmask_base) {
+ unmask_offset = d->chip->unmask_base -
+ d->chip->mask_base;
+ ret = regmap_update_bits(d->map,
+ reg + unmask_offset,
+ d->mask_buf[i],
+ d->mask_buf[i]);
+ } else
ret = regmap_update_bits(map, reg,
d->mask_buf[i], d->mask_buf[i]);
if (ret != 0) {
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 8fc0bfd..f98fe9f 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -800,6 +800,8 @@ struct regmap_irq {
*
* @status_base: Base status register address.
* @mask_base: Base mask register address.
+ * @unmask_base: Base unmask register address. for chips who have
+ *separate mask and unmask registers
* @ack_base:Base ack address. If zero then the chip is clear on read.
* Using zero value is possible with @use_ack bit.
* @wake_base: Base address for wake enables. If zero unsupported.
@@ -820,6 +822,7 @@ struct regmap_irq_chip {
unsigned int status_base;
unsigned int mask_base;
+ unsigned int unmask_base;
unsigned int ack_base;
unsigned int wake_base;
unsigned int irq_reg_stride;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible netlink autobind regression
On Wed, Sep 16, 2015 at 10:02:00PM -0700, Cong Wang wrote:
>
> This part doesn't look correct, seems it is checking if this is a kernel
> netlink socket rather than if it is bound. But I am not sure...
Good point. I've changed it so that bound is only set for non-kernel
sockets.
---8<---
netlink: Fix autobind race condition that leads to zero port ID
The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink:
Reset portid after netlink_insert failure") introduced a race
condition where if two threads tried to autobind the same socket
one of them may end up with a zero port ID.
This patch reverts that commit and instead fixes it by introducing
a separte "bound" variable to indicate whether a user-space socket
has been bound.
Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
Reported-by: Tejun Heo
Reported-by: Linus Torvalds
Signed-off-by: Herbert Xu
Reviewed-by: Cong Wang
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index dea9253..42013c5 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1068,7 +1068,7 @@ static int netlink_insert(struct sock *sk, u32 portid)
lock_sock(sk);
err = -EBUSY;
- if (nlk_sk(sk)->portid)
+ if (nlk_sk(sk)->bound)
goto err;
err = -ENOMEM;
@@ -1083,10 +1083,12 @@ static int netlink_insert(struct sock *sk, u32 portid)
if (err) {
if (err == -EEXIST)
err = -EADDRINUSE;
- nlk_sk(sk)->portid = 0;
sock_put(sk);
+ goto err;
}
+ nlk_sk(sk)->bound = !!portid;
+
err:
release_sock(sk);
return err;
@@ -1253,7 +1255,7 @@ static int netlink_release(struct socket *sock)
skb_queue_purge(>sk_write_queue);
- if (nlk->portid) {
+ if (nlk->bound) {
struct netlink_notify n = {
.net = sock_net(sk),
.protocol = sk->sk_protocol,
@@ -1487,7 +1489,7 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
return err;
}
- if (nlk->portid)
+ if (nlk->bound)
if (nladdr->nl_pid != nlk->portid)
return -EINVAL;
@@ -1505,7 +1507,7 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
}
}
- if (!nlk->portid) {
+ if (!nlk->bound) {
err = nladdr->nl_pid ?
netlink_insert(sk, nladdr->nl_pid) :
netlink_autobind(sock);
@@ -1553,7 +1555,7 @@ static int netlink_connect(struct socket *sock, struct
sockaddr *addr,
!netlink_allowed(sock, NL_CFG_F_NONROOT_SEND))
return -EPERM;
- if (!nlk->portid)
+ if (!nlk->bound)
err = netlink_autobind(sock);
if (err == 0) {
@@ -2371,7 +2373,7 @@ static int netlink_sendmsg(struct socket *sock, struct
msghdr *msg, size_t len)
dst_group = nlk->dst_group;
}
- if (!nlk->portid) {
+ if (!nlk->bound) {
err = netlink_autobind(sock);
if (err)
goto out;
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index 8900840..e6aae40 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -35,6 +35,7 @@ struct netlink_sock {
unsigned long state;
size_t max_recvmsg_len;
wait_queue_head_t wait;
+ boolbound;
boolcb_running;
struct netlink_callback cb;
struct mutex*cb_mutex;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] mfd: add CSR SiRFSoC on-chip power management module driver
From: Guo Zeng
CSR SiRFSoC Power Control Module includes power on or power
off for sysctl power and gnss, it also includes onkey, RTC
domain clock controllers and interrupt controller for power
events.
Signed-off-by: Guo Zeng
Signed-off-by: Barry Song
---
.../devicetree/bindings/mfd/sirf-pwrc.txt | 37
drivers/mfd/Kconfig| 12 ++
drivers/mfd/Makefile | 2 +
drivers/mfd/sirfsoc_pwrc.c | 238 +
include/linux/mfd/sirfsoc_pwrc.h | 97 +
5 files changed, 386 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
create mode 100644 drivers/mfd/sirfsoc_pwrc.c
create mode 100644 include/linux/mfd/sirfsoc_pwrc.h
diff --git a/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
b/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
new file mode 100644
index 000..b919cdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
@@ -0,0 +1,37 @@
+SiRFSoC Power Controller (PWRC) module
+
+Power Controller is used to control the whole SoC power process.
+The power controller controls the process of Power-On sequence,
+Power-Off sequence, different power modes switching and power
+status configuration. the pwrc is access by io bridge, so the
+node's parent should be io bridge.
+
+Required properties:
+- compatible: "sirf,prima2-pwrc", or "sirf,atlas7-pwrc"
+- reg: Address range of pwrc register set
+- sysctl:mfd cell device of pwrc
+- rtcm-clk:mfd cell device of pwrc
+- onkey:mfd cell device of pwrc
+
+Example:
+
+pwrc@3000 {
+ compatible = "sirf,atlas7-pwrc";
+ reg = <0x3000 0x100>;
+ sysctl {
+ compatible = "sirf,sirf-sysctl";
+ };
+
+ rtcm-clk {
+ compatible = "sirf,atlas7-rtcmclk";
+ };
+
+ onkey {
+ compatible = "sirf,prima2-onkey";
+ };
+};
+
+pwrc@3000 {
+ compatible = "sirf,prima2-pwrc";
+ reg = <0x3000 0x100>;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d6367..5b67bee 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1515,5 +1515,17 @@ config MFD_VEXPRESS_SYSREG
System Registers are the platform configuration block
on the ARM Ltd. Versatile Express board.
+config MFD_SIRFSOC_PWRC
+bool "CSR SiRFSoC on-chip Power Control Module"
+ depends on ARCH_SIRF
+ default y
+select MFD_CORE
+select REGMAP_IRQ
+help
+ CSR SiRFSoC Power Control Module includes power on or power
+off for sysctl power and gnss, it also includes onkey, RTC
+domain clock controllers and interrupt controller for power
+events.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fc..255fb80 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -192,3 +192,5 @@ obj-$(CONFIG_MFD_SKY81452) += sky81452.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
+
+obj-$(CONFIG_MFD_SIRFSOC_PWRC) += sirfsoc_pwrc.o
diff --git a/drivers/mfd/sirfsoc_pwrc.c b/drivers/mfd/sirfsoc_pwrc.c
new file mode 100644
index 000..b43f8b4
--- /dev/null
+++ b/drivers/mfd/sirfsoc_pwrc.c
@@ -0,0 +1,238 @@
+/*
+ * power management mfd for CSR SiRFSoC chips
+ *
+ * Copyright (c) 2014 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sirfsoc_pwrc_register sirfsoc_a7da_pwrc = {
+ .pwrc_pdn_ctrl_set = 0x0,
+ .pwrc_pdn_ctrl_clr = 0x4,
+ .pwrc_pon_status = 0x8,
+ .pwrc_trigger_en_set = 0xc,
+ .pwrc_trigger_en_clr = 0x10,
+ .pwrc_int_mask_set = 0x14,
+ .pwrc_int_mask_clr = 0x18,
+ .pwrc_int_status = 0x1c,
+ .pwrc_pin_status = 0x20,
+ .pwrc_rtc_pll_ctrl = 0x28,
+ .pwrc_gpio3_debug = 0x34,
+ .pwrc_rtc_noc_pwrctl_set = 0x38,
+ .pwrc_rtc_noc_pwrctl_clr = 0x3c,
+ .pwrc_rtc_can_ctrl = 0x48,
+ .pwrc_rtc_can_status = 0x4c,
+ .pwrc_fsm_m3_ctrl = 0x50,
+ .pwrc_fsm_state = 0x54,
+ .pwrc_rtcldo_reg = 0x58,
+ .pwrc_gnss_ctrl = 0x5c,
+ .pwrc_gnss_status = 0x60,
+ .pwrc_xtal_reg = 0x64,
+ .pwrc_xtal_ldo_mux_sel = 0x68,
+ .pwrc_rtc_sw_rstc_set = 0x6c,
+ .pwrc_rtc_sw_rstc_clr = 0x70,
+ .pwrc_power_sw_ctrl_set = 0x74,
+ .pwrc_power_sw_ctrl_clr = 0x78,
+ .pwrc_rtc_dcog = 0x7c,
+ .pwrc_m3_memories = 0x80,
+ .pwrc_can0_memory = 0x84,
+ .pwrc_rtc_gnss_memory = 0x88,
+ .pwrc_m3_clk_en = 0x8c,
+ .pwrc_can0_clk_en = 0x90,
+ .pwrc_spi0_clk_en = 0x94,
+ .pwrc_rtc_sec_clk_en = 0x98,
+ .pwrc_rtc_noc_clk_en = 0x9c,
+};
+
+struct
[PATCH v2 2/3] regmap: irq: add ack_invert flag for chips using cleared bits as ack
From: Guo Zeng
An user will be CSR SiRFSoC ARM chips.
Signed-off-by: Guo Zeng
Signed-off-by: Barry Song
---
drivers/base/regmap/regmap-irq.c | 12 ++--
include/linux/regmap.h | 2 ++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 1821c3b..14af2c6 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -132,7 +132,11 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
if (d->mask_buf[i] && (d->chip->ack_base || d->chip->use_ack)) {
reg = d->chip->ack_base +
(i * map->reg_stride * d->irq_reg_stride);
- ret = regmap_write(map, reg, d->mask_buf[i]);
+ /* some chips ack by write 0 */
+ if (d->chip->ack_invert)
+ ret = regmap_write(map, reg, ~d->mask_buf[i]);
+ else
+ ret = regmap_write(map, reg, d->mask_buf[i]);
if (ret != 0)
dev_err(d->map->dev, "Failed to ack 0x%x: %d\n",
reg, ret);
@@ -469,7 +473,11 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
if (d->status_buf[i] && (chip->ack_base || chip->use_ack)) {
reg = chip->ack_base +
(i * map->reg_stride * d->irq_reg_stride);
- ret = regmap_write(map, reg,
+ if (chip->ack_invert)
+ ret = regmap_write(map, reg,
+ ~(d->status_buf[i] & d->mask_buf[i]));
+ else
+ ret = regmap_write(map, reg,
d->status_buf[i] & d->mask_buf[i]);
if (ret != 0) {
dev_err(map->dev, "Failed to ack 0x%x: %d\n",
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index f98fe9f..f36c9f9 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -809,6 +809,7 @@ struct regmap_irq {
* @init_ack_masked: Ack all masked interrupts once during initalization.
* @mask_invert: Inverted mask register: cleared bits are masked out.
* @use_ack: Use @ack register even if it is zero.
+ * @ack_invert: Inverted ack register: cleared bits for ack.
* @wake_invert: Inverted wake register: cleared bits are wake enabled.
* @runtime_pm: Hold a runtime PM lock on the device when accessing it.
*
@@ -829,6 +830,7 @@ struct regmap_irq_chip {
bool init_ack_masked:1;
bool mask_invert:1;
bool use_ack:1;
+ bool ack_invert:1;
bool wake_invert:1;
bool runtime_pm:1;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4,1/2] powerpc32: memcpy: only use dcbz once cache is enabled
On Wed, 2015-16-09 at 10:04:51 UTC, LEROY Christophe wrote: > memcpy() uses instruction dcbz to speed up copy by not wasting time > loading cache line with data that will be overwritten. > Some platform like mpc52xx do no have cache active at startup and > can therefore not use memcpy(). Allthough no part of the code > explicitly uses memcpy(), GCC makes calls to it. > > This patch modifies memcpy() such that at startup, memcpy() > unconditionally jumps to generic_memcpy() which doesn't use > the dcbz instruction. > > Once the initial MMU is set up, in machine_init() we patch memcpy() > by replacing this inconditional jump by a NOP > > Reported-by: Michal Sojka > Signed-off-by: Christophe Leroy Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/1cd03890ea64795e53f17a94 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4,2/2] powerpc32: memset: only use dcbz once cache is enabled
On Wed, 2015-16-09 at 10:04:53 UTC, LEROY Christophe wrote: > memset() uses instruction dcbz to speed up clearing by not wasting time > loading cache line with data that will be overwritten. > Some platform like mpc52xx do no have cache active at startup and > can therefore not use memset(). Allthough no part of the code > explicitly uses memset(), GCC may make calls to it. > > This patch modifies memset() such that at startup, memset() > unconditionally skip the optimised bloc that uses dcbz instruction. > > Once the initial MMU is set up, in machine_init() we patch memset() > by replacing this inconditional jump by a NOP > > Signed-off-by: Christophe Leroy Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/400c47d81ca383fc87d5a393 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 03/16] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters
2015-09-17 0:57 GMT-04:00 Greg Kroah-Hartman :
>> @@ -1748,8 +1755,9 @@ static short rtl8192_usb_initendpoints(struct
>> net_device *dev)
>> oldaddr = priv->oldaddr;
>> align = ((long)oldaddr) & 3;
>> if (align) {
>> - newaddr = oldaddr + 4 - align;
>> - priv->rx_urb[16]->transfer_buffer_length = 16 - 4 +
>> align;
>> + align = 4 - align;
>> + newaddr = oldaddr + align;
>> + priv->rx_urb[16]->transfer_buffer_length = 16 - align;
>
> At a quick glance, this conversion looks wrong...
What is wrong with it?
oldaddr + 4 - align;
can also be read:
oldaddr + (4 - align);
as well as
16 - 4 + align;
can also be read
16 - (4 - align);
as when we remove the parenthesis, the - sign invert the parenthesis
elements signs.
Calculating (4 - align) previously thus preserve the logic here!
> And it's not what your changelog text said you were doing :(
It's true that I didn't add a new temporary variable here but instead
re-used one that is not used after, but I thought it went in the same
idea as the rest of this patch. Should I separate that as another
patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Darlehen Angebot 2%
-- Guten Tag, Sind Sie in der Notwendigkeit einer Kredit? Im Allgemeinen Credit Acceptance in Großbritannien. Wir sind zertifiziert Darlehen Kreditgeber bietet Darlehen an Menschen, die in Not von Darlehen bieten wir Wohnungsbaudarlehen, Investoren Darlehen, Schuldenkonsolidierung Darlehen, zweite Hypothek Darlehen, Business-Darlehen, persönliche Darlehen, internationale Darlehen usw., zu niedrigeren Zinssatz von 2% liegen. pro Jahr, Bewerben Sie sich jetzt und geben Sie Ihren Kreditbetrag Bedürfnisse und Dauer. Interessiert Antragsteller sollte füllen Sie das folgende Informationen. Voller Name: Kontakt Adresse:.. Telefon: Land ... Betrag als Darlehen benötigt: Dauer der Ausleihe: Geschlecht: .. Wir erwarten Ihre dringliche Zusammenarbeit, um unseren Service, damit wir senden Ihnen weitere Informationen. Freundliche Grüße. Credit Acceptance Corporation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible netlink autobind regression
On Wed, Sep 16, 2015 at 8:41 PM, Herbert Xu wrote:
> On Thu, Sep 17, 2015 at 11:08:45AM +0800, Herbert Xu wrote:
>>
>> Good catch! I think your explanation makes perfect sense. Linus
>> ran into this previously too after suspend-and-resume.
>
> Unfortunately you can't just postpone the setting of portid because
> once you pass it onto rhashtable the portid must never change while
> it's in custody.
>
> So what I've done is essentially revert my previous fix and instead
> add a new boolean "bound" to indicate whether the socket has been
> bound.
>
> ---8<---
> netlink: Fix autobind race condition that leads to zero port ID
>
> The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink:
> Reset portid after netlink_insert failure") introduced a race
> condition where if two threads tried to autobind the same socket
> one of them may end up with a zero port ID.
>
> This patch reverts that commit and instead fixes it by introducing
> a separte "bound" variable to indicate whether a socket has been
> bound.
>
> Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
> Reported-by: Tejun Heo
> Reported-by: Linus Torvalds
We saw similar soft lockup with the one Tejun reported, in our data
center.
> Signed-off-by: Herbert Xu
Just one comment below.
[...]
> @@ -1285,7 +1287,7 @@ static int netlink_release(struct socket *sock)
>
> skb_queue_purge(>sk_write_queue);
>
> - if (nlk->portid) {
> + if (nlk->bound) {
> struct netlink_notify n = {
> .net = sock_net(sk),
> .protocol = sk->sk_protocol,
This part doesn't look correct, seems it is checking if this is a kernel
netlink socket rather than if it is bound. But I am not sure...
Other than this, looks good to me:
Reviewed-by: Cong Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/31] fs/cifs: use kmemdup rather than duplicating its implementation
loooks reasonable to me - isn't this part of a larger patch series
though? Did you want it merged distinctly into cifs-2.6.git?
On Fri, Aug 7, 2015 at 2:59 AM, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
>
> Signed-off-by: Andrzej Hajda
> ---
> fs/cifs/smb2pdu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 070fb2a..2d6b72f 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1394,14 +1394,13 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
> *tcon, u64 persistent_fid,
> goto ioctl_exit;
> }
>
> - *out_data = kmalloc(*plen, GFP_KERNEL);
> + *out_data = kmemdup(rsp->hdr.ProtocolId +
> le32_to_cpu(rsp->OutputOffset),
> + *plen, GFP_KERNEL);
> if (*out_data == NULL) {
> rc = -ENOMEM;
> goto ioctl_exit;
> }
>
> - memcpy(*out_data, rsp->hdr.ProtocolId +
> le32_to_cpu(rsp->OutputOffset),
> - *plen);
> ioctl_exit:
> free_rsp_buf(resp_buftype, rsp);
> return rc;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 03/16] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters
On Fri, Sep 11, 2015 at 03:29:11AM -0400, Raphaël Beamonte wrote:
> Add some temporary variables to reduce line length under the maximum
> of 80 characters, as per the kernel code style.
>
> Signed-off-by: Raphaël Beamonte
> ---
> drivers/staging/rtl8192u/r8192U_core.c | 139
> ++---
> 1 file changed, 94 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 37c17eb..c8724cd 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -177,6 +177,7 @@ static void rtl819x_set_channel_map(u8 channel_plan,
> struct r8192_priv *priv)
> {
> int i, max_chan = -1, min_chan = -1;
> struct ieee80211_device *ieee = priv->ieee80211;
> + struct CHANNEL_LIST cl;
>
> switch (channel_plan) {
> case COUNTRY_CODE_FCC:
> @@ -200,15 +201,18 @@ static void rtl819x_set_channel_map(u8 channel_plan,
> struct r8192_priv *priv)
>"unknown rf chip, can't set channel map in
> function:%s()\n",
>__func__);
> }
> - if (ChannelPlan[channel_plan].Len != 0) {
> + cl = ChannelPlan[channel_plan];
> + if (cl.Len != 0) {
> /* Clear old channel map */
> memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
> sizeof(GET_DOT11D_INFO(ieee)->channel_map));
> /* Set new channel map */
> - for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
> - if (ChannelPlan[channel_plan].Channel[i] <
> min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
> + for (i = 0; i < cl.Len; i++) {
> + u8 chan = cl.Channel[i];
> +
> + if (chan < min_chan || chan > max_chan)
> break;
> -
> GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
> + GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
> }
> }
> break;
> @@ -1699,9 +1703,12 @@ short rtl8192_tx(struct net_device *dev, struct
> sk_buff *skb)
> , 0, tx_zero_isr, dev);
> status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
> if (status) {
> + atomic_t tx =
> + priv->tx_pending[tcb_desc->queue_index];
> +
> RT_TRACE(COMP_ERR,
>"Error TX URB for zero byte %d, error
> %d",
> -
> atomic_read(>tx_pending[tcb_desc->queue_index]),
> + atomic_read(),
>status);
> return -1;
> }
> @@ -1748,8 +1755,9 @@ static short rtl8192_usb_initendpoints(struct
> net_device *dev)
> oldaddr = priv->oldaddr;
> align = ((long)oldaddr) & 3;
> if (align) {
> - newaddr = oldaddr + 4 - align;
> - priv->rx_urb[16]->transfer_buffer_length = 16 - 4 +
> align;
> + align = 4 - align;
> + newaddr = oldaddr + align;
> + priv->rx_urb[16]->transfer_buffer_length = 16 - align;
At a quick glance, this conversion looks wrong...
And it's not what your changelog text said you were doing :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 02/16] staging: rtl8192u: r8192U_core: add line breaks to keep lines under 80 characters
On Fri, Sep 11, 2015 at 03:29:10AM -0400, Raphaël Beamonte wrote:
> Add line breaks in multiple lines to keep them under 80 characters,
> as to follow the kernel code style.
>
> Signed-off-by: Raphaël Beamonte
> ---
> drivers/staging/rtl8192u/r8192U_core.c | 626
> ++---
> 1 file changed, 421 insertions(+), 205 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 5e9d0ac..37c17eb 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -144,25 +144,31 @@ struct CHANNEL_LIST {
>
> static struct CHANNEL_LIST ChannelPlan[] = {
> /* FCC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
> 149, 153, 157, 161, 165}, 24},
> + {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
> + 149, 153, 157, 161, 165}, 24},
But now these look worse than before. I say just leave these long
variables as-is.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: fsl-mc: up-rev version of MC interface code
On Tue, Sep 15, 2015 at 03:22:00PM -0500, J. German Rivera wrote: > The DPAA2 management complex has a versioned binary interface > that has to be kept in sync with the DPAA2 drivers. This patch > uprevs the APIs that build MC commands and parse results. > This uprev is needed to support object interrupts. > > MC binary interface changes >-overall version from 6.0 to 8.0 >-dprc version from 3.0 to 4.0 >-dpbp and dpmcp versions from 2.0 to 2.1 >-new dprc commands -- set/get obj irq, set obj label, > get obj descriptor >-removed commands -- get portal paddr >-object regions are reported as region offsets not physical > addresses > > build/parse API changes >-flags arg is added to all APIs for future extensibility, > hardcoded priority bit is now a flag >-IRQ-related args are consolidated into an irq_cfg struct > > Signed-off-by: J. German Rivera > --- > drivers/staging/fsl-mc/bus/dpbp.c | 141 ++--- > drivers/staging/fsl-mc/bus/dpmcp-cmd.h | 2 +- > drivers/staging/fsl-mc/bus/dpmcp.c | 123 +--- > drivers/staging/fsl-mc/bus/dpmcp.h | 123 +--- > drivers/staging/fsl-mc/bus/dpmng.c | 14 +- > drivers/staging/fsl-mc/bus/dprc-cmd.h | 7 +- > drivers/staging/fsl-mc/bus/dprc-driver.c| 8 +- > drivers/staging/fsl-mc/bus/dprc.c | 464 > +++- > drivers/staging/fsl-mc/bus/mc-allocator.c | 6 +- > drivers/staging/fsl-mc/bus/mc-bus.c | 54 +++- > drivers/staging/fsl-mc/include/dpbp-cmd.h | 2 +- > drivers/staging/fsl-mc/include/dpbp.h | 91 -- > drivers/staging/fsl-mc/include/dpcon-cmd.h | 2 +- > drivers/staging/fsl-mc/include/dpmng.h | 14 +- > drivers/staging/fsl-mc/include/dprc.h | 313 +++ > drivers/staging/fsl-mc/include/mc-cmd.h | 28 +- > drivers/staging/fsl-mc/include/mc-private.h | 15 +- > 17 files changed, 1052 insertions(+), 355 deletions(-) This patch does many things all at once. Please break it up into different logical patches, each one only doing one thing, and send it as a series so that it can be properly reviewed and applied to the tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: wilc1000: Added new lines
On Wed, Sep 16, 2015 at 05:42:42PM +0530, Aparna Karuthodi wrote: > Added new lines after declarations for removing coding style warnings > detected by checkpatch.The warnings are given below: > > 1561: WARNING: Missing a blank line after declarations > 1551: WARNING: Missing a blank line after declarations > 1329: WARNING: Missing a blank line after declarations > 1213: WARNING: Missing a blank line after declarations > 1158: WARNING: Missing a blank line after declarations > 1104: WARNING: Missing a blank line after declarations > 675: WARNING: Missing a blank line after declarations > > Signed-off-by: Aparna Karuthodi > --- > drivers/staging/wilc1000/coreconfigurator.c |7 +++ > 1 file changed, 7 insertions(+) Does not apply to my tree :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: wilc1000: Added spaces
On Thu, Sep 17, 2015 at 12:12:50AM +0530, Aparna Karuthodi wrote:
> Added spaces around '=' to remove coding style errors detected by
> checkpatch.The errors are given below:
> drivers/staging/wilc1000/host_interface.c:7951: ERROR: spaces required
> around that '=' (ctx:VxV)
> drivers/staging/wilc1000/host_interface.c:7952: ERROR: spaces required
> around that '=' (ctx:VxW)
>
> Signed-off-by: Aparna Karuthodi
> ---
> drivers/staging/wilc1000/host_interface.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c
> b/drivers/staging/wilc1000/host_interface.c
> index 6b10bbb..d1fe73d 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -7945,8 +7945,8 @@ s32 host_int_get_ipaddress(WILC_WFIDrvHandle hWFIDrv,
> u8 *u16ipadd, u8 idx)
> strHostIFmsg.u16MsgId = HOST_IF_MSG_GET_IPADDRESS;
>
> strHostIFmsg.uniHostIFmsgBody.strHostIfSetIP.au8IPAddr = u16ipadd;
> - strHostIFmsg.drvHandler=hWFIDrv;
> - strHostIFmsg.uniHostIFmsgBody.strHostIfSetIP.idx= idx;
> + strHostIFmsg.drvHandler = hWFIDrv;
> + strHostIFmsg.uniHostIFmsgBody.strHostIfSetIP.idx = idx;
>
> s32Error = WILC_MsgQueueSend(, ,
> sizeof(tstrHostIFmsg), NULL);
> if (s32Error) {
> --
> 1.7.9.5
Does not apply to my tree :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] USB fixes for v4.3-rc2
On Wed, Sep 16, 2015 at 11:45:19AM -0500, Felipe Balbi wrote: > Hi Greg, > > Here's the first set of fixes for v4.3-rc cycle. Please consider > merging. Patches have been tested on platforms I have around > (AM437x, AM335x, DRA7x) and have been in next for a few days. > > Let me know if you want anything to be changed > > cheers > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/fixes-for-v4.3-rc2 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Wed, Sep 16, 2015 at 11:48:59PM -0400, Chris Mason wrote: > On Thu, Sep 17, 2015 at 10:37:38AM +1000, Dave Chinner wrote: > > [cc Tejun] > > > > On Thu, Sep 17, 2015 at 08:07:04AM +1000, Dave Chinner wrote: > > # ./fs_mark -D 1 -S0 -n 1 -s 4096 -L 120 -d > > /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/2 -d /mnt/scratch/3 > > -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d > > /mnt/scratch/7 > > # Version 3.3, 8 thread(s) starting at Thu Sep 17 08:08:36 2015 > > # Sync method: NO SYNC: Test does not issue sync() or fsync() calls. > > # Directories: Time based hash between directories across 1 > > subdirectories with 180 seconds per subdirectory. > > # File names: 40 bytes long, (16 initial bytes of time stamp with 24 > > random bytes at end of name) > > # Files info: size 4096 bytes, written with an IO size of 16384 bytes > > per write > > # App overhead is time in microseconds spent in the test not doing > > file writing related system calls. > > > > FSUse%Count SizeFiles/sec App Overhead > > 08 4096 106938.0 543310 > > 0 16 4096 102922.7 476362 > > 0 24 4096 107182.9 538206 > > 0 32 4096 107871.7 619821 > > 0 40 4096 99255.6 622021 > > 0 48 4096 103217.8 609943 > > 0 56 4096 96544.2 640988 > > 0 64 4096 100347.3 676237 > > 0 72 4096 87534.8 483495 > > 0 80 4096 72577.5 2556920 > > 0 88 4096 97569.0 646996 > > > > > > I think too many variables have changed here. > > My numbers: > > FSUse%Count SizeFiles/sec App Overhead > 0 16 4096 356407.1 1458461 > 0 32 4096 368755.1 1030047 > 0 48 4096 358736.8 992123 > 0 64 4096 361912.5 1009566 > 0 80 4096 342851.4 1004152 > I can push the dirty threshold lower to try and make sure we end up in > the hard dirty limits but none of this is going to be related to the > plugging patch. The point of this test is to drive writeback as hard as possible, not to measure how fast we can create files in memory. i.e. if the test isn't pushing the dirty limits on your machines, then it really isn't putting a meaningful load on writeback, and so the plugging won't make significant difference because writeback isn't IO bound > I do see lower numbers if I let the test run even > longer, but there are a lot of things in the way that can slow it down > as the filesystem gets that big. Sure, that's why I hit the dirty limits early in the test - so it measures steady state performance before the fs gets to any significant scalability limits > > The baseline of no plugging is a full 3 minutes faster than the > > plugging behaviour of Linus' patch. The IO behaviour demonstrates > > that, sustaining between 25-30,000 IOPS and throughput of > > 130-150MB/s. Hence, while Linus' patch does change the IO patterns, > > it does not result in a performance improvement like the original > > plugging patch did. > > How consistent is this across runs? That's what I'm trying to work out. I didn't report it until I got consistently bad results - the numbers I reported were from the third time I ran the comparison, and they were representative and reproducable. I also ran my inode creation workload that is similar (but has not data writeback so doesn't go through writeback paths at all) and that shows no change in performance, so this problem (whatever it is) is only manifesting itself through data writeback The only measurable change I've noticed in my monitoring graphs is that there is a lot more iowait time than I normally see, even when the plugging appears to be working as desired. That's what I'm trying to track down now, and once I've got to the bottom of that I should have some idea of where the performance has gone As it is, there are a bunch of other things going wrong with 4.3-rc1+ right now that I'm working through - I haven't updated my kernel tree for 10 days because I've been away on holidays so I'm doing my usual "-rc1 is broken again" dance that I do every release cycle. (e.g every second boot hangs because systemd appears to be waiting for iscsi devices to appear without first starting the iscsi target daemon. Never happened before today, every new kernel I've booted today has hung on the first cold boot of the VM). > > IOWs, what we are seeing here is that the baseline writeback > > performance has regressed quite
Re: [PATCH] Staging: lustre: lustre: mdc: lproc_mdc.c: declared file_operations struct as const
On Wed, Sep 16, 2015 at 06:01:01PM +0530, Sakshi Vaid wrote:
> Declared the file_operations structure as const as done elsewhere in the
> kernel, as there are no modifiactions to this field.
>
> Following warning found by checkpatch
> WARNING: struct file_operations should normally be const
>
> Signed-off-by: Sakshi Vaid
> ---
> drivers/staging/lustre/lustre/mdc/lproc_mdc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
> b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
> index c791941..c62c0ac 100644
> --- a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
> +++ b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
> @@ -146,7 +146,7 @@ static ssize_t mdc_kuc_write(struct file *file,
> return count;
> }
>
> -struct file_operations mdc_kuc_fops = {
> +const struct file_operations mdc_kuc_fops = {
> .open = mdc_kuc_open,
> .write = mdc_kuc_write,
> .release= single_release,
This doesn't apply to my tree at all, what are you making it against?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: lustre: lustre: mgc: mgc_request.c: Removed unnecessary space
On Wed, Sep 16, 2015 at 06:27:12PM +0530, Sakshi Vaid wrote:
> Removed the unnecessary space in the declaration of a pointer.
> The following error was given.
> ERROR: "foo * bar" should be "foo *bar"
>
> Signed-off-by: Sakshi Vaid
> ---
> drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c
> b/drivers/staging/lustre/lustre/mgc/mgc_request.c
> index 60d2b0f..8d3dbdc 100644
> --- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
> +++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
> @@ -160,7 +160,7 @@ struct config_llog_data *config_log_find(char *logname,
> {
> struct config_llog_data *cld;
> struct config_llog_data *found = NULL;
> - void * instance;
> + void *instance;
>
> LASSERT(logname != NULL);
>
This also doesn't apply :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the libata tree
Hi Tejun,
After merging the libata tree, today's linux-next build (powercp
allmodconfig) failed like this:
drivers/ata/pata_macio.c:1347:1: error: 'pata_macio_patch' undeclared here (not
in a function)
drivers/ata/pata_macio.c:1347:1: error:
'__mod_of__pata_macio_patch_device_table' aliased to undefined symbol
'pata_macio_patch'
Caused by commit
5d8619769cf5 ("ata: pata_macio: Fix module autoload for OF platform driver")
A simple typo ("patch" v "match"), but clearly never build tested.
Only found after the release.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/13] Move bp_type_idx to kernel/event/hw_breakpoint.c
On Tue, 15 Sep 2015 12:39:10 PDT (-0700), pet...@infradead.org wrote:
> On Tue, Sep 15, 2015 at 11:40:11AM -0700, Palmer Dabbelt wrote:
>> On Tue, 15 Sep 2015 01:06:07 PDT (-0700), pet...@infradead.org wrote:
>> > On Mon, Sep 14, 2015 at 03:50:43PM -0700, Palmer Dabbelt wrote:
>> >> This has a "#ifdef CONFIG_*" that used to be exposed to userspace.
>> >>
>> >> The names in here are so generic that I don't think it's a good idea
>> >> to expose them to userspace (or even the rest of the kernel). Since
>> >> there's only one kernel user, it's been moved to that file.
>> >>
>> >> Signed-off-by: Palmer Dabbelt
>> >> Reviewed-by: Andrew Waterman
>> >> Reviewed-by: Albert Ou
>> >> ---
>> >> include/uapi/linux/hw_breakpoint.h | 10 --
>> >> kernel/events/hw_breakpoint.c | 10 ++
>> >> 2 files changed, 10 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/include/uapi/linux/hw_breakpoint.h
>> >> b/include/uapi/linux/hw_breakpoint.h
>> >> index b04000a2296a..7a6a5a7f9511 100644
>> >> --- a/include/uapi/linux/hw_breakpoint.h
>> >> +++ b/include/uapi/linux/hw_breakpoint.h
>> >> @@ -17,14 +17,4 @@ enum {
>> >> HW_BREAKPOINT_INVALID = HW_BREAKPOINT_RW | HW_BREAKPOINT_X,
>> >> };
>> >>
>> >> -enum bp_type_idx {
>> >> - TYPE_INST = 0,
>> >> -#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>> >> - TYPE_DATA = 0,
>> >> -#else
>> >> - TYPE_DATA = 1,
>> >> -#endif
>> >> - TYPE_MAX
>> >> -};
>> >
>> > This is rather unfortunate; you are correct that the naming is too
>> > generic (and I tend to agree), but I think these values are required by
>> > userspace to fill out:
>> >
>> > perf_event_attr::bp_type
>> >
>> > So removing them will break things.
>> >
>> > Frederic?
>>
>> perf_event_open(2) says
>>
>>bp_type (since Linux 2.6.33)
>> This chooses the breakpoint type. It is one of:
>>
>> HW_BREAKPOINT_EMPTY
>> No breakpoint.
>>
>> HW_BREAKPOINT_R
>> Count when we read the memory location.
>>
>> HW_BREAKPOINT_W
>> Count when we write the memory location.
>>
>> HW_BREAKPOINT_RW
>> Count when we read or write the memory location.
>>
>> HW_BREAKPOINT_X
>> Count when we execute code at the memory location.
>>
>> The values can be combined via a bitwise or, but the
>> combination
>> of HW_BREAKPOINT_R or HW_BREAKPOINT_W with HW_BREAKPOINT_X
>> is
>> not allowed.
>>
>> so I think removing this enum from userspace is OK. Did I miss
>> something?
>
> Nah, could've just been me not being awake. Unless Frederic says
> otherwise I'll chalk it up to not having drank enough morning juice.
Well, I'm going to leave this alone, then -- as Arnd pointed out in a
later email that got mis-threaded, this would be super tricky to fix
if userspace actually relied on it (which is why I was scared I was
wrong).
v4 (which is hopefully the final version of the patch set) will leave
this as it is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Thu, Sep 17, 2015 at 10:37:38AM +1000, Dave Chinner wrote: > [cc Tejun] > > On Thu, Sep 17, 2015 at 08:07:04AM +1000, Dave Chinner wrote: > > On Wed, Sep 16, 2015 at 04:00:12PM -0400, Chris Mason wrote: > > > On Wed, Sep 16, 2015 at 09:58:06PM +0200, Jan Kara wrote: > > > > On Wed 16-09-15 11:16:21, Chris Mason wrote: > > > > > Short version, Linus' patch still gives bigger IOs and similar perf to > > > > > Dave's original. I should have done the blktrace runs for 60 seconds > > > > > instead of 30, I suspect that would even out the average sizes between > > > > > the three patches. > > > > > > > > Thanks for the data Chris. So I guess we are fine with what's currently > > > > in, > > > > right? > > > > > > Looks like it works well to me. > > > > Graph looks good, though I'll confirm it on my test rig once I get > > out from under the pile of email and other stuff that is queued up > > after being away for a week... > > I ran some tests in the background while reading other email. > > TL;DR: Results look really bad - not only is the plugging > problematic, baseline writeback performance has regressed > significantly. We need to revert the plugging changes until the > underlying writeback performance regressions are sorted out. > > In more detail, these tests were run on my usual 16p/16GB RAM > performance test VM with storage set up as described here: > > https://urldefense.proofpoint.com/v1/url?u=http://permalink.gmane.org/gmane.linux.kernel/1768786=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0A=4Qwp5Zj8CpoMb6vOcz%2FNMQ%2Fsb0%2FamLUP1vqWgedxJL0%3D%0A=90b54e35a4a7fcc4bcab9e15e22c025c7c9e045541e4923500f2e3258fc1952b > > The test: > > $ ~/tests/fsmark-10-4-test-xfs.sh > meta-data=/dev/vdc isize=512agcount=500, agsize=268435455 > blks > = sectsz=512 attr=2, projid32bit=1 > = crc=1finobt=1, sparse=0 > data = bsize=4096 blocks=134217727500, imaxpct=1 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > log =internal log bsize=4096 blocks=131072, version=2 > = sectsz=512 sunit=1 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > # ./fs_mark -D 1 -S0 -n 1 -s 4096 -L 120 -d > /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/2 -d /mnt/scratch/3 > -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d /mnt/scratch/7 > # Version 3.3, 8 thread(s) starting at Thu Sep 17 08:08:36 2015 > # Sync method: NO SYNC: Test does not issue sync() or fsync() calls. > # Directories: Time based hash between directories across 1 > subdirectories with 180 seconds per subdirectory. > # File names: 40 bytes long, (16 initial bytes of time stamp with 24 > random bytes at end of name) > # Files info: size 4096 bytes, written with an IO size of 16384 bytes > per write > # App overhead is time in microseconds spent in the test not doing file > writing related system calls. > > FSUse%Count SizeFiles/sec App Overhead > 08 4096 106938.0 543310 > 0 16 4096 102922.7 476362 > 0 24 4096 107182.9 538206 > 0 32 4096 107871.7 619821 > 0 40 4096 99255.6 622021 > 0 48 4096 103217.8 609943 > 0 56 4096 96544.2 640988 > 0 64 4096 100347.3 676237 > 0 72 4096 87534.8 483495 > 0 80 4096 72577.5 2556920 > 0 88 4096 97569.0 646996 > > I think too many variables have changed here. My numbers: FSUse%Count SizeFiles/sec App Overhead 0 16 4096 356407.1 1458461 0 32 4096 368755.1 1030047 0 48 4096 358736.8 992123 0 64 4096 361912.5 1009566 0 80 4096 342851.4 1004152 0 96 4096 358357.2 996014 0 112 4096 338025.8 1004412 0 128 4096 354440.3 997380 0 144 4096 335225.9 1000222 0 160 4096 278786.1 1164962 0 176 4096 268161.4 1205255 0 192 4096 259158.0 1298054 0 208 4096 276939.1 1219411 0 224 4096 252385.1 1245496
Re: Possible netlink autobind regression
On Thu, Sep 17, 2015 at 11:08:45AM +0800, Herbert Xu wrote:
>
> Good catch! I think your explanation makes perfect sense. Linus
> ran into this previously too after suspend-and-resume.
Unfortunately you can't just postpone the setting of portid because
once you pass it onto rhashtable the portid must never change while
it's in custody.
So what I've done is essentially revert my previous fix and instead
add a new boolean "bound" to indicate whether the socket has been
bound.
---8<---
netlink: Fix autobind race condition that leads to zero port ID
The commit c0bb07df7d981e4091432754e30c9c720e2c0c78 ("netlink:
Reset portid after netlink_insert failure") introduced a race
condition where if two threads tried to autobind the same socket
one of them may end up with a zero port ID.
This patch reverts that commit and instead fixes it by introducing
a separte "bound" variable to indicate whether a socket has been
bound.
Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
Reported-by: Tejun Heo
Reported-by: Linus Torvalds
Signed-off-by: Herbert Xu
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7f86d3b..abcbca5 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1095,7 +1095,7 @@ static int netlink_insert(struct sock *sk, u32 portid)
lock_sock(sk);
err = -EBUSY;
- if (nlk_sk(sk)->portid)
+ if (nlk_sk(sk)->bound)
goto err;
err = -ENOMEM;
@@ -1115,10 +1115,12 @@ static int netlink_insert(struct sock *sk, u32 portid)
err = -EOVERFLOW;
if (err == -EEXIST)
err = -EADDRINUSE;
- nlk_sk(sk)->portid = 0;
sock_put(sk);
+ goto err;
}
+ nlk_sk(sk)->bound = true;
+
err:
release_sock(sk);
return err;
@@ -1285,7 +1287,7 @@ static int netlink_release(struct socket *sock)
skb_queue_purge(>sk_write_queue);
- if (nlk->portid) {
+ if (nlk->bound) {
struct netlink_notify n = {
.net = sock_net(sk),
.protocol = sk->sk_protocol,
@@ -1519,7 +1521,7 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
return err;
}
- if (nlk->portid)
+ if (nlk->bound)
if (nladdr->nl_pid != nlk->portid)
return -EINVAL;
@@ -1537,7 +1539,7 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
}
}
- if (!nlk->portid) {
+ if (!nlk->bound) {
err = nladdr->nl_pid ?
netlink_insert(sk, nladdr->nl_pid) :
netlink_autobind(sock);
@@ -1585,7 +1587,7 @@ static int netlink_connect(struct socket *sock, struct
sockaddr *addr,
!netlink_allowed(sock, NL_CFG_F_NONROOT_SEND))
return -EPERM;
- if (!nlk->portid)
+ if (!nlk->bound)
err = netlink_autobind(sock);
if (err == 0) {
@@ -2426,7 +2428,7 @@ static int netlink_sendmsg(struct socket *sock, struct
msghdr *msg, size_t len)
dst_group = nlk->dst_group;
}
- if (!nlk->portid) {
+ if (!nlk->bound) {
err = netlink_autobind(sock);
if (err)
goto out;
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index 8900840..e6aae40 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -35,6 +35,7 @@ struct netlink_sock {
unsigned long state;
size_t max_recvmsg_len;
wait_queue_head_t wait;
+ boolbound;
boolcb_running;
struct netlink_callback cb;
struct mutex*cb_mutex;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] Staging: wilc1000: Use NULL instead of zero
On Wed, 2015-09-16 at 20:15 -0700, Greg KH wrote: > On Thu, Sep 17, 2015 at 08:28:52AM +0530, roni wrote: > > Sorry for the ambiguity. > > I am talking about my second patch in the series. > > https://lkml.org/lkml/2015/9/15/293 > > > > > > None of the line edited in first patch haven't changed after that. > > > > You applied the version 1 of the first patch in the series > > https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=0e04f3f381c6a3ab3a7ef0ec9ded709e95996527 > > > > Since then those lines I changed in the patch mentioned above haven't > > changed. > > > > Why my second patch in this series doesn't apply? > > I don't remember, that was many hundreds of patches ago, sorry. Try it > yourself to see if I messed up. Perhaps someone else had already sent > in that same change before you did? git-apply shows no error if I apply second patch on staging/staging-testing. regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v8 03/13] KVM: Define a new interface kvm_intr_is_single_vcpu()
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, September 16, 2015 5:23 PM
> To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org;
> mtosa...@redhat.com
> Cc: eric.au...@linaro.org; k...@vger.kernel.org;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v8 03/13] KVM: Define a new interface
> kvm_intr_is_single_vcpu()
>
>
>
> On 16/09/2015 10:49, Feng Wu wrote:
> > This patch defines a new interface kvm_intr_is_single_vcpu(),
> > which can returns whether the interrupt is for single-CPU or not.
> >
> > It is used by VT-d PI, since now we only support single-CPU
> > interrupts, For lowest-priority interrupts, if user configures
> > it via /proc/irq or uses irqbalance to make it single-CPU, we
> > can use PI to deliver the interrupts to it. Full functionality
> > of lowest-priority support will be added later.
> >
> > Signed-off-by: Feng Wu
> > ---
> > v8:
> > - Some optimizations in kvm_intr_is_single_vcpu().
> > - Expose kvm_intr_is_single_vcpu() so we can use it in vmx code.
> > - Add kvm_intr_is_single_vcpu_fast() as the fast path to find
> > the target vCPU for the single-destination interrupt
> >
> > arch/x86/include/asm/kvm_host.h | 3 ++
> > arch/x86/kvm/irq_comm.c | 94
> +
> > arch/x86/kvm/lapic.c| 5 +--
> > arch/x86/kvm/lapic.h| 2 +
> > 4 files changed, 101 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/kvm_host.h
> b/arch/x86/include/asm/kvm_host.h
> > index 49ec903..af11bca 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -1204,4 +1204,7 @@ int __x86_set_memory_region(struct kvm *kvm,
> > int x86_set_memory_region(struct kvm *kvm,
> > const struct kvm_userspace_memory_region *mem);
> >
> > +bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
> > +struct kvm_vcpu **dest_vcpu);
> > +
> > #endif /* _ASM_X86_KVM_HOST_H */
> > diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> > index 9efff9e..97ba1d6 100644
> > --- a/arch/x86/kvm/irq_comm.c
> > +++ b/arch/x86/kvm/irq_comm.c
> > @@ -297,6 +297,100 @@ out:
> > return r;
> > }
> >
> > +static bool kvm_intr_is_single_vcpu_fast(struct kvm *kvm,
> > +struct kvm_lapic_irq *irq,
> > +struct kvm_vcpu **dest_vcpu)
>
> Please put this in lapic.c, similar to kvm_irq_delivery_to_apic_fast, so
> that you do not have to export other functions.
>
> > +{
> > + struct kvm_apic_map *map;
> > + bool ret = false;
> > + struct kvm_lapic *dst = NULL;
> > +
> > + if (irq->shorthand)
> > + return false;
> > +
> > + rcu_read_lock();
> > + map = rcu_dereference(kvm->arch.apic_map);
> > +
> > + if (!map)
> > + goto out;
> > +
> > + if (irq->dest_mode == APIC_DEST_PHYSICAL) {
> > + if (irq->dest_id == 0xFF)
> > + goto out;
> > +
> > + if (irq->dest_id >= ARRAY_SIZE(map->phys_map)) {
>
> Warning here is wrong, the guest can trigger it.
Could you please share more information about how the guest
triggers these conditions (including the following two), Thanks
a lot!
Thanks,
Feng
>
> > + WARN_ON_ONCE(1);
> > + goto out;
> > + }
> > +
> > + dst = map->phys_map[irq->dest_id];
> > + if (dst && kvm_apic_present(dst->vcpu))
> > + *dest_vcpu = dst->vcpu;
> > + else
> > + goto out;
> > + } else {
> > + u16 cid;
> > + unsigned long bitmap = 1;
> > + int i, r = 0;
> > +
> > + if (!kvm_apic_logical_map_valid(map)) {
> > + WARN_ON_ONCE(1);
>
> Same here.
>
> > + goto out;
> > + }
> > +
> > + apic_logical_id(map, irq->dest_id, , (u16 *));
> > +
> > + if (cid >= ARRAY_SIZE(map->logical_map)) {
> > + WARN_ON_ONCE(1);
>
> Same here.
>
> Otherwise looks good.
>
> Paolo
>
> > + goto out;
> > + }
> > +
> > + for_each_set_bit(i, , 16) {
> > + dst = map->logical_map[cid][i];
> > + if (++r == 2)
> > + goto out;
> > + }
> > +
> > + if (dst && kvm_apic_present(dst->vcpu))
> > + *dest_vcpu = dst->vcpu;
> > + else
> > + goto out;
> > + }
> > +
> > + ret = true;
> > +out:
> > + rcu_read_unlock();
> > + return ret;
> > +}
> > +
> > +
> > +bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
> > +struct kvm_vcpu **dest_vcpu)
> > +{
> > + int i, r = 0;
> > + struct kvm_vcpu *vcpu;
> > +
> > + if (kvm_intr_is_single_vcpu_fast(kvm, irq, dest_vcpu))
> > +
Re: [PATCH v2 1/2] Staging: wilc1000: Use NULL instead of zero
On Thu, Sep 17, 2015 at 08:28:52AM +0530, roni wrote: > Sorry for the ambiguity. > I am talking about my second patch in the series. > https://lkml.org/lkml/2015/9/15/293 > > > > None of the line edited in first patch haven't changed after that. > > You applied the version 1 of the first patch in the series > https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=0e04f3f381c6a3ab3a7ef0ec9ded709e95996527 > > Since then those lines I changed in the patch mentioned above haven't > changed. > > Why my second patch in this series doesn't apply? I don't remember, that was many hundreds of patches ago, sorry. Try it yourself to see if I messed up. Perhaps someone else had already sent in that same change before you did? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [sched/numa] 2a595721a1: No primary change, -4.1% pigz.time.system_time, -35.6% pigz.time.involuntary_context_switches
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 2a595721a1fa6b684c1c818f379bef834ac3d65e ("sched/numa: Convert
sched_numa_balancing to a static_branch")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/nr_threads/blocksize:
brickland1/pigz/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/25%/512K
commit:
2b49d84b259fc18e131026e5d38e7855352f71b9
2a595721a1fa6b684c1c818f379bef834ac3d65e
2b49d84b259fc18e 2a595721a1fa6b684c1c818f37
--
%stddev %change %stddev
\ |\
8893 ± 3% -35.6% 5725 ± 2%
pigz.time.involuntary_context_switches
529645 ± 7% -84.6% 81746 ± 2% pigz.time.minor_page_faults
136.12 ± 0% -4.1% 130.53 ± 0% pigz.time.system_time
49894 ± 0% -12.0% 43908 ± 0% vmstat.system.in
23110 ± 4% +10.4% 25504 ± 3% numa-meminfo.node2.Active(file)
34491 ± 7% +9.9% 37902 ± 7% numa-meminfo.node3.SUnreclaim
2198559 ± 85%+298.4%8759838 ± 40% numa-numastat.node3.local_node
2201064 ± 85%+298.1%8762796 ± 40% numa-numastat.node3.numa_hit
8893 ± 3% -35.6% 5725 ± 2% time.involuntary_context_switches
529645 ± 7% -84.6% 81746 ± 2% time.minor_page_faults
921.83 ± 0% +4.0% 958.44 ± 0% turbostat.CorWatt
935.50 ± 0% +3.9% 972.09 ± 0% turbostat.PkgWatt
1210520 ±116%+466.6%6858564 ±173%
latency_stats.avg.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
1210520 ±116%+466.6%6858564 ±173%
latency_stats.max.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
1210520 ±116%+466.6%6858564 ±173%
latency_stats.sum.nfs_wait_on_request.nfs_updatepage.nfs_write_end.generic_perform_write.__generic_file_write_iter.generic_file_write_iter.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
5777 ± 4% +10.4% 6375 ± 3% numa-vmstat.node2.nr_active_file
8622 ± 7% +9.9% 9475 ± 7%
numa-vmstat.node3.nr_slab_unreclaimable
1397511 ±112%+225.2%4545159 ± 45% numa-vmstat.node3.numa_hit
1344766 ±116%+234.2%4494534 ± 45% numa-vmstat.node3.numa_local
446934 ± 9%-100.0% 0.00 ± -1% proc-vmstat.numa_hint_faults
156287 ± 8%-100.0% 0.00 ± -1% proc-vmstat.numa_hint_faults_local
79222 ± 3%-100.0% 0.00 ± -1% proc-vmstat.numa_pages_migrated
606436 ± 10%-100.0% 0.00 ± -1% proc-vmstat.numa_pte_updates
1325944 ± 3% -34.0% 875483 ± 0% proc-vmstat.pgfault
2944 ± 22%-100.0% 0.00 ± -1% proc-vmstat.pgmigrate_fail
79222 ± 3%-100.0% 0.00 ± -1% proc-vmstat.pgmigrate_success
1.66 ± 88% -90.3% 0.16 ± 35%
perf-profile.cpu-cycles.__acct_update_integrals.acct_account_cputime.account_user_time.account_process_tick.update_process_times
51.92 ± 11% -18.3% 42.43 ± 14%
perf-profile.cpu-cycles.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt.smp_apic_timer_interrupt.apic_timer_interrupt
29.38 ± 7% -23.4% 22.52 ± 14%
perf-profile.cpu-cycles.ktime_get.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt
29.13 ± 7% -23.4% 22.32 ± 13%
perf-profile.cpu-cycles.read_hpet.ktime_get.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt
1.17 ± 31%+112.8% 2.48 ± 17%
perf-profile.cpu-cycles.read_hpet.update_wall_time.tick_do_update_jiffies64.tick_sched_do_timer.tick_sched_timer
1.78 ± 32%+107.3% 3.70 ± 13%
perf-profile.cpu-cycles.tick_do_update_jiffies64.tick_sched_do_timer.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt
1.78 ± 32%+107.4% 3.70 ± 13%
perf-profile.cpu-cycles.tick_sched_do_timer.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt
50.82 ± 11% -18.1% 41.61 ± 14%
perf-profile.cpu-cycles.tick_sched_timer.__hrtimer_run_queues.hrtimer_interrupt.local_apic_timer_interrupt.smp_apic_timer_interrupt
1.77 ± 32%+106.6% 3.67 ± 13%
perf-profile.cpu-cycles.update_wall_time.tick_do_update_jiffies64.tick_sched_do_timer.tick_sched_timer.__hrtimer_run_queues
116261 ± 3% -24.1% 88256 ± 7% sched_debug.cfs_rq[0]:/.exec_clock
3830581 ± 1% -24.8%2878817 ± 7%
sched_debug.cfs_rq[0]:/.min_vruntime
133.00 ± 55% -98.7% 1.67 ± 74%
Re: [PATCH V2] dummy_hcd: replace timeval with timespec64
add Alan Stern
On Thursday, September 17, 2015 11:09 AM, WEN Pingbo wrote:
> The millisecond of the last second will be normal if tv_sec is
> overflowed. But for y2038 consistency and demonstration purpose,
> and avoiding further risks, we need to remove 'timeval' in this
> driver, to avoid similair problems.
>
> V2 Updates:
> - using monotonic time here by replacing getnstimeofday() with
> ktime_get_ts64(), to avoid leap second issues. The frame time in USB
> is always 1ms, no matter what speed, so ktime_get_ts64() have enough
> resolution to cover this.
> - using NSEC_PER_MSEC instead of hard code.
>
> Signed-off-by: Pingbo Wen
> Cc: Y2038
> Cc: linux-kernel@vger.kernel.org
> Cc: Arnd Bergmann
> Cc: Felipe Balbi
> Signed-off-by: WEN Pingbo
> ---
> drivers/usb/gadget/udc/dummy_hcd.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
> b/drivers/usb/gadget/udc/dummy_hcd.c
> index 1379ad4..6d1ed35 100644
> --- a/drivers/usb/gadget/udc/dummy_hcd.c
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
> + struct timespec64 tv;
>
> - do_gettimeofday();
> - return tv.tv_usec / 1000;
> + ktime_get_ts64();
> + return tv.tv_nsec / NSEC_PER_MSEC;
> }
>
> static int dummy_wakeup(struct usb_gadget *_gadget)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] dummy_hcd: replace timeval with timespec64
The millisecond of the last second will be normal if tv_sec is
overflowed. But for y2038 consistency and demonstration purpose,
and avoiding further risks, we need to remove 'timeval' in this
driver, to avoid similair problems.
V2 Updates:
- using monotonic time here by replacing getnstimeofday() with
ktime_get_ts64(), to avoid leap second issues. The frame time in USB
is always 1ms, no matter what speed, so ktime_get_ts64() have enough
resolution to cover this.
- using NSEC_PER_MSEC instead of hard code.
Signed-off-by: Pingbo Wen
Cc: Y2038
Cc: linux-kernel@vger.kernel.org
Cc: Arnd Bergmann
Cc: Felipe Balbi
Signed-off-by: WEN Pingbo
---
drivers/usb/gadget/udc/dummy_hcd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index 1379ad4..6d1ed35 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
/* there are both host and device side versions of this call ... */
static int dummy_g_get_frame(struct usb_gadget *_gadget)
{
- struct timeval tv;
+ struct timespec64 tv;
- do_gettimeofday();
- return tv.tv_usec / 1000;
+ ktime_get_ts64();
+ return tv.tv_nsec / NSEC_PER_MSEC;
}
static int dummy_wakeup(struct usb_gadget *_gadget)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible netlink autobind regression
On Wed, Sep 16, 2015 at 10:29:09PM -0400, Tejun Heo wrote: > > Anyways, after the patch, it seems something like the following could > happen. Good catch! I think your explanation makes perfect sense. Linus ran into this previously too after suspend-and-resume. I'll look into it. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/13] Always define MAX_RAW_MINORS as 65535 in userspace
On Tue, 15 Sep 2015 13:42:47 PDT (-0700), h...@zytor.com wrote: > On 09/14/2015 03:50 PM, Palmer Dabbelt wrote: >> While I don't think this was ever meant to be exposed to userspace, if >> anyone is using it then this will at least provide a correct (if >> unlikely) definition. >> >> MAX_RAW_MINORS used to be used in the kernel, where it's been replaced >> with CONFIG_MAX_RAW_MINORS. >> >> Note that there's a checkpatch.pl warning about a split config string >> here, but I've left that alone. > > From a UAPI perspective I would think the right value would be 2^20. Wow, I'm super surprised. For some reason I thought major/minor numbers were 16 bits, but according to glibc I just have no idea what I'm doing :). Thanks for catching this! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/17/2015 03:42, Mark Brown wrote: On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote: I try to use one entry, but there is a problem. It's about 'driver_data' in struct device. In function snd_soc_register_card, the parameter 'card' will be set to 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. Then some resources(eg. regmap, clock) also need be recorded by 'driver_data'. One entry could only has one 'driver_data'. I think the best way is to create two entries, like the current dts. What's your opinion? Look at the recently applied sunxi driver for an example of how to do this - it's a similar piece of hardware (entirely in the SoC and so on). Thank you, It really helps me. I will make a second version soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 17
Hi all, Changes since 20150916: Unropped tree: akpm-current I used the h8300 tree from next-20150828 since the current tree has been rebased onto something very old :-( The drm-intel tree gained a conflict against Linus' tree. The net-next tree lost its build failure. The bluetooth tree still had its build failure. I worked around the tip tree build failure. The akpm-current tree lost its build failure but gained another for which I applied a fix patch. Non-merge commits (relative to Linus' tree): 1731 1614 files changed, 79032 insertions(+), 19790 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 226 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (72714841b705 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (c2172ce23030 Merge branch 'uaccess' into fixes) Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (36b35d5d807b powerpc/mm: Recompute hash value after a failed update) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (20471ed4d403 dccp: drop null test before destroy functions) Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in _decode_session6) Merging sound-current/for-linus (5ee20bc79246 ALSA: usb-audio: Change internal PCM order) Merging pci-current/for-linus (237865f195f6 PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code") Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (6ff33f3902c3 Linux 4.3-rc1) Merging tty.current/tty-linus (6ff33f3902c3 Linux 4.3-rc1) Merging usb.current/usb-linus (6ff33f3902c3 Linux 4.3-rc1) Merging usb-gadget-fixes/fixes (762982db33b2 usb: phy: phy-generic: Fix reset behaviour on legacy boot) Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs) Merging staging.current/staging-linus (8b5081c876bd staging: unisys: visornic: handle error return from device registration) Merging char-misc.current/char-misc-linus (6ff33f3902c3 Linux 4.3-rc1) Merging input-current/for-linus (53431d0a3534 Merge branch 'next' into for-linus) Merging crypto-current/master (84cba178a3b8 crypto: testmgr - don't copy from source IV too much) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default emit rule) Merging backlight-fixes/for-backlight
Re: [PATCH v2 1/2] Staging: wilc1000: Use NULL instead of zero
Sorry for the ambiguity. I am talking about my second patch in the series. https://lkml.org/lkml/2015/9/15/293 > > None of the line edited in first patch haven't changed after that. You applied the version 1 of the first patch in the series https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=0e04f3f381c6a3ab3a7ef0ec9ded709e95996527 Since then those lines I changed in the patch mentioned above haven't changed. Why my second patch in this series doesn't apply? regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [ACPI] 73a092e801: cannot_create/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor:Directory_nonexistent
FYI, we noticed the below changes on
git://linux-arm.org/linux-skn acpi_lpi
commit 73a092e801e9938496b71acc9434fb33a9d65d34 ("ACPI: tables: simplify
acpi_parse_entries")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/ip/runtime/nr_threads/cluster/test:
lkp-nex04/netperf/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/ipv4/300s/200%/cs-localhost/UDP_RR
commit:
34f6273d2bb1ddd7da4f9fe4babc78b0a60ad71f
73a092e801e9938496b71acc9434fb33a9d65d34
34f6273d2bb1ddd7 73a092e801e9938496b71acc94
--
fail:runs %reproductionfail:runs
| | |
:10 100% 10:10
stderr./lkp/lkp/src/setup/cpufreq_governor:#:/lkp/lkp/src/setup/cpufreq_governor:cannot_create/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor:Directory_nonexistent
:10 100% 10:10
last_state.cpufreq_governor.exit_code.2
:10 100% 10:10last_state.exit_fail
:10 100% 10:10last_state.is_incomplete_run
lkp-nex04: Nehalem-EX
Memory: 256G
In short, the cpufrequ_governor sysfs interface is not available after
your commit. Caused ACPI cpufreq driver to stop working?
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Ying Huang
---
LKP_SERVER: inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
testcase: netperf
default-monitors:
wait: activate-monitor
kmsg:
uptime:
iostat:
vmstat:
numa-numastat:
numa-vmstat:
numa-meminfo:
proc-vmstat:
proc-stat:
interval: 10
meminfo:
slabinfo:
interrupts:
lock_stat:
latency_stats:
softirqs:
bdi_dev_mapping:
diskstats:
nfsstat:
cpuidle:
cpufreq-stats:
turbostat:
pmeter:
sched_debug:
interval: 60
cpufreq_governor: performance
default-watchdogs:
oom-killer:
watchdog:
commit: 9568ddba4675103560f78e1525d4d605e1d87311
model: Nehalem-EX
memory: 256G
nr_cpu: 64
nr_ssd_partitions: 6
ssd_partitions: "/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F059074-part1"
swap_partitions: "/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F059074-part2"
category: benchmark
ip: ipv4
runtime: 300s
nr_threads: 200%
perf-profile:
freq: 800
cluster: cs-localhost
if role server:
netserver:
if role client:
netperf:
test: UDP_RR
queue: cyclic
testbox: lkp-nex04
tbox_group: lkp-nex04
kconfig: x86_64-rhel
enqueue_time: 2015-09-15 20:49:52.315197050 +08:00
id: 4d1b45d439da0570b237d2aa3cae834c253a6bbd
user: lkp
compiler: gcc-4.9
head_commit: 9568ddba4675103560f78e1525d4d605e1d87311
base_commit: 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f
branch: linux-devel/devel-hourly-2015091603
kernel:
"/pkg/linux/x86_64-rhel/gcc-4.9/9568ddba4675103560f78e1525d4d605e1d87311/vmlinuz-4.3.0-rc1-wl-ath-00970-g9568ddb"
rootfs: debian-x86_64-2015-02-07.cgz
node_roles: server client
result_root:
"/result/netperf/performance-ipv4-300s-200%-cs-localhost-UDP_RR/lkp-nex04/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/9568ddba4675103560f78e1525d4d605e1d87311/0"
job_file:
"/lkp/scheduled/lkp-nex04/cyclic_netperf-performance-ipv4-300s-200%-cs-localhost-UDP_RR-x86_64-rhel-CYCLIC_HEAD-9568ddba4675103560f78e1525d4d605e1d87311-20150915-83542-da4zpv-0.yaml"
dequeue_time: 2015-09-16 03:51:24.555683406 +08:00
max_uptime: 1500
initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
-
job=/lkp/scheduled/lkp-nex04/cyclic_netperf-performance-ipv4-300s-200%-cs-localhost-UDP_RR-x86_64-rhel-CYCLIC_HEAD-9568ddba4675103560f78e1525d4d605e1d87311-20150915-83542-da4zpv-0.yaml
- ARCH=x86_64
- kconfig=x86_64-rhel
- branch=linux-devel/devel-hourly-2015091603
- commit=9568ddba4675103560f78e1525d4d605e1d87311
-
BOOT_IMAGE=/pkg/linux/x86_64-rhel/gcc-4.9/9568ddba4675103560f78e1525d4d605e1d87311/vmlinuz-4.3.0-rc1-wl-ath-00970-g9568ddb
- max_uptime=1500
-
RESULT_ROOT=/result/netperf/performance-ipv4-300s-200%-cs-localhost-UDP_RR/lkp-nex04/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/9568ddba4675103560f78e1525d4d605e1d87311/0
- LKP_SERVER=inn
- |2-
earlyprintk=ttyS0,115200 systemd.log_level=err
debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200 console=tty0 vga=normal
rw
lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz"
modules_initrd:
[PATCH] staging/lustre: use __noreturn for lbug_with_loc
fixes sparse error:
drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c:149:6: error:
symbol 'lbug_with_loc'redeclared with different type (originally declared at
drivers/staging/lustre/lustre/libcfs/linux/../../../include/linux/libcfs/libcfs_private.h:82)
- different modifiers
Use the __noreturn macro instead of __attribute__((noreturn))
The macro is exactly that but its usage seems more common and
it is bit more readable.
Signed-off-by: Juston Li
---
drivers/staging/lustre/include/linux/libcfs/libcfs_private.h | 2 +-
drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
index 9544860..6af733d 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
@@ -79,7 +79,7 @@ do {
\
#define KLASSERT(e) LASSERT(e)
-void lbug_with_loc(struct libcfs_debug_msg_data *)__attribute__((noreturn));
+void __noreturn lbug_with_loc(struct libcfs_debug_msg_data *);
#define LBUG() \
do { \
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
index 4545d54..8689ea7 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c
@@ -146,7 +146,7 @@ void libcfs_run_lbug_upcall(struct libcfs_debug_msg_data
*msgdata)
}
/* coverity[+kill] */
-void lbug_with_loc(struct libcfs_debug_msg_data *msgdata)
+void __noreturn lbug_with_loc(struct libcfs_debug_msg_data *msgdata)
{
libcfs_catastrophe = 1;
libcfs_debug_msg(msgdata, "LBUG\n");
--
2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation
On Wed, Sep 16, 2015 at 12:07:06PM +0100, Will Deacon wrote:
> On Wed, Sep 16, 2015 at 11:43:14AM +0100, Peter Zijlstra wrote:
> > On Wed, Sep 16, 2015 at 11:29:08AM +0100, Will Deacon wrote:
> > > > Indeed, that is a hole in the definition, that I think we should close.
> >
> > > I'm struggling to understand the hole, but here's my intuition. If an
> > > ACQUIRE on CPUx reads from a RELEASE by CPUy, then I'd expect CPUx to
> > > observe all memory accessed performed by CPUy prior to the RELEASE
> > > before it observes the RELEASE itself, regardless of this new barrier.
> > > I think this matches what we currently have in memory-barriers.txt (i.e.
> > > acquire/release are neither transitive or multi-copy atomic).
> >
> > Ah agreed. I seem to have gotten my brain in a tangle.
> >
> > Basically where a program order release+acquire relies on an address
> > dependency, a cross cpu release+acquire relies on causality. If we
> > observe the release, we must also observe everything prior to it etc.
>
> Yes, and crucially, the "everything prior to it" only encompasses accesses
> made by the releasing CPU itself (in the absence of other barriers and
> synchronisation).
>
Just want to make sure I understand you correctly, do you mean that in
the following case:
CPU 1 CPU 2 CPU 3
== ===
{ A = 0, B = 0 }
WRITE_ONCE(A,1);r1 = READ_ONCE(A); r2 =
smp_load_acquire();
smp_store_release(, 1); r3 = READ_ONCE(A);
r1 == 1 && r2 == 1 && r3 == 0 is not prohibitted?
However, according to the discussion of Paul and Peter:
https://lkml.org/lkml/2015/9/15/707
I think that's prohibitted on architectures except s390 for sure. And
for s390, we are waiting for the maintainers to verify this. If s390
also prohibits this, then a release-acquire pair(on different CPUs) to
the same variable does guarantee transitivity.
Did I misunderstand you or miss something here?
> Given that we managed to get confused, it doesn't hurt to call this out
> explicitly in the doc, so I can add the following extra text.
>
> Will
>
> --->8
>
> diff --git a/Documentation/memory-barriers.txt
> b/Documentation/memory-barriers.txt
> index 46a85abb77c6..794d102d06df 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1902,8 +1902,8 @@ the RELEASE would simply complete, thereby avoiding the
> deadlock.
> a sleep-unlock race, but the locking primitive needs to resolve
> such races properly in any case.
>
> -If necessary, ordering can be enforced by use of an
> -smp_mb__release_acquire() barrier:
> +Where the RELEASE and ACQUIRE operations are performed by the same CPU,
> +ordering can be enforced by use of an smp_mb__release_acquire() barrier:
>
> *A = a;
> RELEASE M
> @@ -1916,6 +1916,10 @@ in which case, the only permitted sequences are:
> STORE *A, RELEASE M, ACQUIRE N, STORE *B
> STORE *A, ACQUIRE N, RELEASE M, STORE *B
>
> +Note that smp_mb__release_acquire() has no effect on ACQUIRE or RELEASE
> +operations performed by other CPUs, even if they are to the same variable.
> +In cases where transitivity is required, smp_mb() should be used explicitly.
> +
Then, IIRC, the memory order effect of RELEASE+ACQUIRE should be:
If an ACQUIRE loads the value of stored by a RELEASE, then on the CPU
executing the ACQUIRE operation, all the memory operations after the
ACQUIRE operation will perceive all the memory operations before the
RELEASE operation on the CPU executing the RELEASE operation.
This could cover both the "on the same CPU" and "on different CPUs"
cases.
Of course, this may has nothing to do with smp_mb__release_acquire(),
but I think we can take this chance to document the memory order effect
of RELEASE+ACQUIRE well.
Regards,
Boqun
> Locks and semaphores may not provide any guarantee of ordering on UP compiled
> systems, and so cannot be counted on in such a situation to actually achieve
> anything at all - especially with respect to I/O accesses - unless combined
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
signature.asc
Description: PGP signature
[PATCH] workqueue: Free useless memory when disabling NUMA in wq_numa_init()
From: Xunlei Pang
wq_update_unbound_numa_attrs_buf and tbl will never be used
in case of invalid NUMA node mapping, so just free them.
Signed-off-by: Xunlei Pang
---
kernel/workqueue.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index ca71582..22d7747 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -5197,6 +5197,13 @@ static void __init wq_numa_init(void)
node = cpu_to_node(cpu);
if (WARN_ON(node == NUMA_NO_NODE)) {
pr_warn("workqueue: NUMA node mapping not available for
cpu%d, disabling NUMA support\n", cpu);
+
+ for_each_node(node)
+ free_cpumask_var(tbl[node]);
+ kfree(tbl);
+
+ free_workqueue_attrs(wq_update_unbound_numa_attrs_buf);
+ wq_update_unbound_numa_attrs_buf = NULL;
/* happens iff arch is bonkers, let's just proceed */
return;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
On Wed, 2015-09-16 at 13:55 +0100, Will Deacon wrote:
> Hello Yong,
>
> On Mon, Sep 14, 2015 at 01:25:00PM +0100, Yong Wu wrote:
> > On Tue, 2015-07-21 at 18:11 +0100, Will Deacon wrote:
> > > > + ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot,
> > > > large);
> > > > +
> > > > + tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
> > > > + tlb->tlb_sync(data->iop.cookie);
> > >
> > > In _arm_short_map, it looks like you can only go from invalid -> valid,
> > > so why do you need to flush the TLB here?
> >
> > Hi Will,
> >Here is about flush-tlb after map iova, I have deleted it in v4
> > following this suggestion. But We meet a problem about it.
>
> Ok.
>
> > Take a example with JPEG. the test steps is:
> > a).JPEG HW decode a picture with the source iova,like 0xfd78.
> > b).JPEG HW decode done, It will unmap the iova(write 0 in pagetable and
> > flush tlb).
> > c).JPEG HW decode the second picture, whose source iova is also
> > 0xfd78.
> >Then our HW maybe fail due to it will auto prefetch, It may prefecth
> > between the step b) and c). then the HW may fetch the pagetable content
> > which has been unmapped in step b). then the HW will get the iova's
> > physical address is 0, It will translation fault!
>
> Oh no! So-called "negative caching" is certainly prohibited by the ARM
> architecture, but if you've built it then we can probably work around it
> as an additional quirk. I assume the prefetcher stops prefetching when
> it sees an invalid descriptor?
Yes, If it's a invalid descriptor, the HW will stop prefetch.
>
> > So I think our HW need flush-tlb after map iova. Could we add a
> > QUIRK like "IO_PGTABLE_QUIRK_AUTO_PREFETCH_ENABLE" for it?
> > If it's not allowed, we will have to add this in our internal function
> > mtk_iommu_map of mtk_iommu.c.
>
> Actually, this type of quirk is ringing bells with me (I think another
> IOMMU needed something similar in the past), so maybe just add
> IO_PGTABLE_QUIRK_TLBI_ON_MAP?
Thanks. I will add it like:
//=
ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);
if (data->iop.cfg.quirk & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
tlb->tlb_sync(data->iop.cookie);
}
//==
It will flush-tlb every time after map-iova. then the HW will fetch the
new PA from the dram.
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Possible netlink autobind regression
Hello,
We're seeing processes piling up on audit_cmd_mutex and after some
digging it turns out sometimes audit_receive() ends up recursing into
itself causing an A-A deadlock on audit_cmd_mutex. Here's the
backtrace.
PID: 1939995 TASK: 88085bdde360 CPU: 27 COMMAND: "crond"
#0 [880369513ae0] __schedule at 818c49e2
#1 [880369513b30] schedule at 818c50e7
#2 [880369513b50] schedule_preempt_disabled at 818c52ce
#3 [880369513b60] __mutex_lock_slowpath at 818c6ad2
#4 [880369513bc0] mutex_lock at 818c6b5b
#5 [880369513be0] audit_receive at 810de5f1
#6 [880369513c10] netlink_unicast at 817c419b
#7 [880369513c60] netlink_ack at 817c4764
#8 [880369513ca0] audit_receive at 810de65a
#9 [880369513cd0] netlink_unicast at 817c419b
#10 [880369513d20] netlink_sendmsg at 817c450a
#11 [880369513da0] sock_sendmsg at 817792ba
#12 [880369513e30] SYSC_sendto at 81779ce0
#13 [880369513f70] sys_sendto at 8177a27e
#14 [880369513f80] system_call_fastpath at 818c8772
RIP: 7fbf652e6913 RSP: 7ffca11d08d8 RFLAGS: 00010202
RAX: ffda RBX: 818c8772 RCX:
RDX: 0070 RSI: 7ffca11d2c50 RDI: 0003
RBP: 7ffca11d2c50 R8: 7ffca11d08f0 R9: 000c
R10: R11: 0246 R12: 8177a27e
R13: 880369513f78 R14: 0060 R15: 0070
ORIG_RAX: 002c CS: 0033 SS: 002b
The weird thing is that netlink_ack() ends up trying to send ack to
the kernel socket instead of the userland sender. This seems only
possible if the issuing socket's portid is 0 for some reason.
c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
made netlink_insert() reset nlk_sk(sk)->portid to zero if insertion
fails. The description says that it prevents sockets which lost
autobinding from being stuck in limbo. I could be mistaken but the
description doesn't seem to be enough - for unconnected sendmsg users,
it looks like the socket would just use the wrong port number likely
occupied by someone else from the second try which would hose ack
routing.
Anyways, after the patch, it seems something like the following could
happen.
thread 1 thread 2
---
netlink_sendmsg()
netlink_autobind()
netlink_insert()
nlk->portid = portid;
__netlink_insert() fails
netlink_sendmsg()
nlk->portid is not zero,
skip autobinding
nlk->portid = 0;
NETLINK_CB(skb).portid is set to zero
...
netlink_ack(skb)
tries to send ack to kernel rx socket
If the above could happen, it would explain the deadlock. The root
problem is that whether to autobind or not is determined by testing
whether nlk->portid is zero without synchronizing against autobind
path and the autobind path may temporarily set and then clear portid
thus tricking the unsynchronized test. The issue can be fixed by only
setting portid after it's known that the port can be used.
That particular issue can be fixed by the following incorrect patch
which needs more work as it ends up temporarily hashing sockets with a
mismatching portid.
Does this make any sense or am I chasing wild geese?
Thanks.
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7f86d3b..6835426 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1037,11 +1037,12 @@ static struct sock *__netlink_lookup(struct
netlink_table *table, u32 portid,
netlink_rhashtable_params);
}
-static int __netlink_insert(struct netlink_table *table, struct sock *sk)
+static int __netlink_insert(struct netlink_table *table, struct sock *sk,
+ int portid)
{
struct netlink_compare_arg arg;
- netlink_compare_arg_init(, sock_net(sk), nlk_sk(sk)->portid);
+ netlink_compare_arg_init(, sock_net(sk), portid);
return rhashtable_lookup_insert_key(>hash, ,
_sk(sk)->node,
netlink_rhashtable_params);
@@ -1103,11 +1104,12 @@ static int netlink_insert(struct sock *sk, u32 portid)
unlikely(atomic_read(>hash.nelems) >= UINT_MAX))
goto err;
- nlk_sk(sk)->portid = portid;
sock_hold(sk);
- err = __netlink_insert(table, sk);
- if (err) {
+ err = __netlink_insert(table, sk, portid);
+ if (!err) {
+ nlk_sk(sk)->portid = portid;
+ } else {
Re: [PATCH v2 1/2] Staging: wilc1000: Use NULL instead of zero
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Sep 17, 2015 at 07:13:39AM +0530, Ronit Halder wrote: > Why not the second one? Second what? > None of the line edited in first patch haven't changed after that. I don't understand what you are asking here :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/page_alloc.c:184:14: error: conflicting types for 'pageblock_order'
unsigned int pageblock_order __read_mostly;
^
In file included from include/linux/mmzone.h:17:0,
from include/linux/gfp.h:5,
from include/linux/mm.h:9,
from mm/page_alloc.c:18:
include/linux/pageblock-flags.h:47:12: note: previous declaration of
'pageblock_order' was here
extern int pageblock_order;
^
Caused by commit
b3c625d32a04 ("mm: use 'unsigned int' for page order")
I assume that this was never built with CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
set (or the hunk that updated include/linux/pageblock-flags.h was missed).
I have added the following fix patch for today:
From: Stephen Rothwell
Date: Thu, 17 Sep 2015 11:58:50 +1000
Subject: [PATCH] mm-use-unsigned-int-for-page-order-fix
Signed-off-by: Stephen Rothwell
---
include/linux/pageblock-flags.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-flags.h
index 2baeee12f48e..e942558b3585 100644
--- a/include/linux/pageblock-flags.h
+++ b/include/linux/pageblock-flags.h
@@ -44,7 +44,7 @@ enum pageblock_bits {
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
/* Huge page sizes are variable */
-extern int pageblock_order;
+extern unsigned int pageblock_order;
#else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
--
2.5.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Wed, Sep 16, 2015 at 06:12:29PM -0700, Linus Torvalds wrote: > On Wed, Sep 16, 2015 at 5:37 PM, Dave Chinner wrote: > > > > TL;DR: Results look really bad - not only is the plugging > > problematic, baseline writeback performance has regressed > > significantly. > > Dave, if you're testing my current -git, the other performance issue > might still be the spinlock thing. I have the fix as the first commit in my local tree - it'll remain there until I get a conflict after an update. :) > The plugging IO pauses are interesting, though. Plugging really > *shouldn't* cause that kind of pauses, _regardless_ of what level it > happens on, so I wonder if the patch ends up just exposing some really > basic problem that just normally goes hidden. Right, that's what I suspect - it didn't happen on older kernels, but we've just completely reworked the writeback code for the control group awareness since I last looked really closely at this... > Can you match up the IO wait times with just *where* it is > waiting? Is it waiting for that inode I_SYNC thing in > inode_sleep_on_writeback()? I'll do some more investigation. > But it does sound like we should just revert the whole plugging for > now, if only because "it has odd effects". Yup - we can add it again next merge window once we get to the bottom of whatever is going on and have had time to test the new code properly. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/27] perf record, bpf: Parse and create probe points for BPF programs
On 2015/9/17 5:43, Arnaldo Carvalho de Melo wrote:
Em Sun, Sep 06, 2015 at 07:13:21AM +, Wang Nan escreveu:
This patch introduces bpf__{un,}probe() functions to enable callers to
create kprobe points based on section names of BPF programs. It parses
Ok, so now I see that when we do:
perf record --event bpf_prog.o usleep 1
We are potentially inserting multiple events, one for each eBPF section
found in bpf_prog.o, right?
Yes.
I.e. multiple evsels, so, when parsing, we should create the kprobes and
from there then create evsels and insert in the normal list that would
eventually get spliced to the evlist being processed, I think.
So, and reading that comment on 4/27, we need to allow that to happen at
parse_events() time, i.e. avoid adding a dummy evsel that would then,
later, be "expanded" into potentially multiple non-dummy evsels.
I put the first 3 patches, with some adjustments, in my perf/ebpf
branch, will try to do the above, i.e. do away with that dummy, allow
parsing the bpf_prog.o sections at parse_events() time.
Then I suggest a small interface modification in libbpf to return
'struct bpf_object *',
then after loading we can iterator on each program in that object, creat
kprobe points
then made evsels. We need to call convert_perf_probe_events() multiple
times for each
object. Since Namhyung updates the probing interface, I think it becomes
possible.
I'm glad to see you will working on this problem. If you have other
ugrent business
to do, I think I can also start this work from Sept. 21 and will have 3
days before
my vacation.
Thank you.
- Arnaldo
the section names of each eBPF program and creates corresponding 'struct
perf_probe_event' structures. The parse_perf_probe_command() function is
used to do the main parsing work.
Parsing result is stored into an array to satisify
{convert,apply}_perf_probe_events(). It accepts an array of
'struct perf_probe_event' and do all the work in one call.
Define PERF_BPF_PROBE_GROUP as "perf_bpf_probe", which will be used as
the group name of all eBPF probing points.
probe_conf.max_probes is set to MAX_PROBES to support glob matching.
Before ending of bpf__probe(), data in each 'struct perf_probe_event' is
cleaned. Things will be changed by following patches because they need
'struct probe_trace_event' in them,
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/n/1436445342-1402-21-git-send-email-wangn...@huawei.com
Link:
http://lkml.kernel.org/n/1436445342-1402-23-git-send-email-wangn...@huawei.com
[Merged by two patches
wangnan: Utilize new perf probe API
{convert,apply,cleanup}_perf_probe_events()
]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-record.c | 19 +-
tools/perf/util/bpf-loader.c | 149 +++
tools/perf/util/bpf-loader.h | 13
3 files changed, 180 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index f886706..b56109f 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1141,7 +1141,23 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
if (err)
goto out_bpf_clear;
- err = -ENOMEM;
+ /*
+* bpf__probe must be called before symbol__init() because we
+* need init_symbol_maps. If called after symbol__init,
+* symbol_conf.sort_by_name won't take effect.
+*
+* bpf__unprobe() is safe even if bpf__probe() failed, and it
+* also calls symbol__init. Therefore, goto out_symbol_exit
+* is safe when probe failed.
+*/
+ err = bpf__probe();
+ if (err) {
+ bpf__strerror_probe(err, errbuf, sizeof(errbuf));
+
+ pr_err("Probing at events in BPF object failed.\n");
+ pr_err("\t%s\n", errbuf);
+ goto out_symbol_exit;
+ }
symbol__init(NULL);
@@ -1202,6 +1218,7 @@ out_symbol_exit:
perf_evlist__delete(rec->evlist);
symbol__exit();
auxtrace_record__free(rec->itr);
+ bpf__unprobe();
out_bpf_clear:
bpf__clear();
return err;
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 88531ea..10505cb 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -9,6 +9,8 @@
#include "perf.h"
#include "debug.h"
#include "bpf-loader.h"
+#include "probe-event.h"
+#include "probe-finder.h"
#define DEFINE_PRINT_FN(name, level) \
static int libbpf_##name(const char *fmt, ...)\
@@ -28,6 +30,58 @@ DEFINE_PRINT_FN(debug, 1)
static bool libbpf_initialized;
+static int
+config_bpf_program(struct bpf_program *prog, struct
Re: [PATCH] mach-s3c64xx:Fix error handling for certain calls to s3c_gpio_cfgpin_range in the file dev-audio.c
On 17.09.2015 10:51, Nicholas Krause wrote:
> This fixes error handling for calls to the function
> s3c_gpio_cfgpin_range in the file dev-audio.c that
> assume calls to this particular function always run
> successfully to properly check now if these calls
> fail by returning a error code and if so return it
> directly to the call of these functions in order for
> the caller to be able to handle these failed calls in
> its own error path(s).
>
> Signed-off-by: Nicholas Krause
> ---
> arch/arm/mach-s3c64xx/dev-audio.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
I am assuming (from the past events) that you did not test the patch and
how returning the error condition affects rest of the code. In the same
time you ignored my request to mark such patches with Request-For-Test.
Please send it after testing.
Commit message is hard to understand, please re-phrase so it would be
easily to find how this affects upper layers.
As you are banned on LKML, the patch needs thorough testing and review
before applying.
Best regards,
Krzysztof
>
> diff --git a/arch/arm/mach-s3c64xx/dev-audio.c
> b/arch/arm/mach-s3c64xx/dev-audio.c
> index ff780a8..81fabdb 100644
> --- a/arch/arm/mach-s3c64xx/dev-audio.c
> +++ b/arch/arm/mach-s3c64xx/dev-audio.c
> @@ -27,6 +27,7 @@
> static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
> {
> unsigned int base;
> + int ret;
>
> switch (pdev->id) {
> case 0:
> @@ -47,9 +48,9 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
> -
> - return 0;
> + ret = s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
> +
> + return ret;
> }
>
> static struct resource s3c64xx_iis0_resource[] = {
> @@ -122,6 +123,7 @@ EXPORT_SYMBOL(s3c64xx_device_iisv4);
> static int s3c64xx_pcm_cfg_gpio(struct platform_device *pdev)
> {
> unsigned int base;
> + int ret;
>
> switch (pdev->id) {
> case 0:
> @@ -136,8 +138,8 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(2));
> - return 0;
> + ret = s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(2));
> + return ret;
> }
>
> static struct resource s3c64xx_pcm0_resource[] = {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: First kernel patch (optimization)
On 09/16/2015 07:56 AM, David Laight wrote:
From: Austin S Hemmelgarn
Sent: 16 September 2015 12:46
On 2015-09-15 20:09, Steve Calfee wrote:
On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote:
Signed-off-by: Eric Curtin
diff --git a/tools/usb/usbip/src/usbip_detach.c
b/tools/usb/usbip/src/usbip_detach.c
index 05c6d15..9db9d21 100644
--- a/tools/usb/usbip/src/usbip_detach.c
+++ b/tools/usb/usbip/src/usbip_detach.c
@@ -47,7 +47,9 @@ static int detach_port(char *port)
uint8_t portnum;
char path[PATH_MAX+1];
-
+ unsigned int port_len = strlen(port);
+
+ for (unsigned int i = 0; i < port_len; i++)
if (!isdigit(port[i])) {
err("invalid port %s", port);
return -1;
--
Hi Eric,
This is fine, but what kind of wimpy compiler optimizer will not move
the constant initializer out of the loop? I bet if you compare binary
sizes/code it will be exactly the same, and you added some characters
of code. Reorganizing code for readability is fine, but for compiler
(in)efficiency seems like a bad idea.
While I agree with your argument, I would like to point out that it is a
well established fact that GCC's optimizers are kind of brain-dead at
times and need their hands held.
I'd be willing to bet that the code will be marginally larger (because
of adding another variable), but might run slightly faster too (because
in my experience, GCC doesn't always catch things like this), and should
compile a little faster (because the optimizers don't have to do as much
work).
The compiler probably can't optimise the strlen().
If isdigit() is a real function (the locale specific one probably is)
then the compile cannot assume that port[n] isn't changed by the call
to isdigit.
A simpler change would be:
for (unsigned int i = 0; port[i] != 0; i++)
Much better would be to use strtoul() instead of atoi().
David
I actually took some time to verify this. GCC makes this optimization
with -O2 at least on gcc 4.7.2.
One interesting observation I found was that in O0 and O2, it does make
a call to strlen while in O1 it calculates
the length of the string using:
repnz scas%es:(%rdi),%al
not%rcx
sub $0x2,%rcx
Why does it do that? Is the code above faster? If yes, why not do it in
O2 too?
Is this still a topic for this forum?
gcc version 4.7.2 (Debian 4.7.2-5)
code
void conv_input(char *port)
{
int portnum;
for(int i = 0; i http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] mmc: dw_mmc: Generic MMC tuning with the clock phase framework
Hi, On 09/16/2015 11:52 PM, Heiko Stübner wrote: > Hi, > > Am Mittwoch, 16. September 2015, 11:30:26 schrieb Jaehoon Chung: >> On 09/16/2015 07:09 AM, Heiko Stübner wrote: >>> Am Dienstag, 15. September 2015, 17:25:38 schrieb Jaehoon Chung: On 09/01/2015 03:24 AM, Heiko Stuebner wrote: > From: Alexandru M Stan > > This algorithm will try 1 degree increments, since there's no way to > tell > what resolution the underlying phase code uses. As an added bonus, doing > many tunings yields better results since some tests are run more than > once > (ex: if the underlying driver uses 45 degree increments, the tuning code > will try the same angle more than once). > > It will then construct a list of good phase ranges (even ranges that > cross > 360/0), will pick the biggest range then it will set the sample_clk to > the > middle of that range. > > We do not touch ciu_drive (and by extension define default-drive-phase). > Drive phase is mostly used to define minimum hold times, while one could > write some code to determine what phase meets the minimum hold time (ex > 10 > degrees) this will not work with the current clock phase framework > (which > floors angles, so we'll get 0 deg, and there's no way to know what > resolution the floors happen at). We assume that the default drive > angles > set by the hardware are good enough. > > If a device has device specific code (like exynos) then that will still > take precedence, otherwise this new code will execute. If the device > wants > to tune, but has no sample_clk defined we'll return EIO with an error > message. Which point is "_generic_"? I don't find the code that control the register relevant to CLK_DRV/SMPL PHASE. It seems that posted the similar patches at u-boot mailing list.. >>> >>> The "generic" part is that it uses the clk phase API for dw_mmc >>> implementations where the clkgen controlling interface is outside the >>> dw_mmc IP itself. So it's open for other implementations as well. >> >> Designware IP also has the CLK phase register(UHS_REG_EXT register)... >> if this code is related with it, it should be located into dw-mmc.c. > > UHS_REG_EXT is acutally "reserved" on both the rk3288 as well as the rk3368. > rk3036/rk3128 (Cortex-A7) provide a bit description, but the tuning > documentation still uses the controls located in the clock controller. > > So I guess UHS_REG_EXT is the real "generic" solution. > >>> But if you are more comfortable with it, I can also move it into the >>> dw_mmc- rockchip variant for the time being, until another user comes >>> along. >> I think more better that this code is located into dw_mmc-rockchip. how >> about? > > As described above, moving that to the rockchip part sounds sensible. And I > guess we can think more about it, once a second user appears. Sure, we can think more about this. As you knew, clock phase is closely related to the timing issue. So clock phase scheme needs to control however. In future, if somebody introduce the similar control as rockchip, we can discuss about it. Best Regards, Jaehoon Chung > > > Heiko > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Ensure proper suspend/resume ordering
On Thu, Sep 17, 2015 at 2:27 AM, Rafael J. Wysocki wrote: > On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: >> On Wed, 16 Sep 2015, Thierry Reding wrote: [cut] > > And I'm wondering if and how that is related to runtime PM? It only > covers the system sleep transitions case, but who's responsible for the > runtime PM part? Device drivers? > Which reminds me of something we all seem to be forgetting about: there is asynchronous suspend and resume which may cause suspend and resume callbacks of devices to be executed in an order that is different from the dpm_list order. In those cases the device that depends on another one has to explicitly wait for the other one to complete its callback in the current phase of the transition. While correct ordering of dpm_list is essential for this to work too, it by no means is sufficient, so in the end the driver having a dependency needs to know about it and act on it as needed (or we need an alternative mechanism that will do that automatically, but I'm not sure what that may be). Actually, I was thinking about adding something like pm_get() for this purpose that will do pm_runtime_get_sync() on the target and will ensure that the right things will happen during system suspend/resume in addition to that, including reordering dpm_list if necessary. Plus, of course, the complementary pm_put(). With something like that available, there should be no need to reorder dpm_list anywhere else. The problem with this approach is that the reordering becomes quite complicated then, as it would need to move the device itself after the target and anything that depends on it along with it and tracking those dependencies becomes quite problematic. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: integrator: Fix module autoload for OF platform driver
On 16-09-15, 22:24, Luis de Bethencourt wrote:
> This platform driver has a OF device ID table but the OF module
> alias information is not created so module autoloading won't work.
>
> Signed-off-by: Luis de Bethencourt
> ---
>
> Hello,
>
> This patch adds the missing MODULE_DEVICE_TABLE() for OF to export
> that information so modules have the correct aliases built-in and
> autoloading works correctly.
>
> A longer explanation by Javier Canillas can be found here:
> https://lkml.org/lkml/2015/7/30/519
>
> Thanks,
> Luis
>
> drivers/cpufreq/integrator-cpufreq.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/integrator-cpufreq.c
> b/drivers/cpufreq/integrator-cpufreq.c
> index 2faa421..79e3ff2 100644
> --- a/drivers/cpufreq/integrator-cpufreq.c
> +++ b/drivers/cpufreq/integrator-cpufreq.c
> @@ -221,6 +221,8 @@ static const struct of_device_id
> integrator_cpufreq_match[] = {
> { },
> };
>
> +MODULE_DEVICE_TABLE(of, integrator_cpufreq_match);
> +
> static struct platform_driver integrator_cpufreq_driver = {
> .driver = {
> .name = "integrator-cpufreq",
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation
On Wed, Sep 16, 2015 at 05:38:14PM +0100, Will Deacon wrote: > On Wed, Sep 16, 2015 at 12:49:18PM +0100, Boqun Feng wrote: > > Hi Will, > > Hello, > > > On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote: > > > +If necessary, ordering can be enforced by use of an > > > +smp_mb__release_acquire() barrier: > > > + > > > + *A = a; > > > + RELEASE M > > > + smp_mb__release_acquire(); > > > > Should this barrier be placed after the ACQUIRE? Because we do actually > > want(?) and allow RELEASE and ACQUIRE operations to reorder in this > > case, like your following example, right? > > I think it's a lot simpler to keep it where it is, in all honesty. The > relaxation for the RELEASE/ACQUIRE access ordering is mainly there to > allow architectures building those operations out of explicit barriers > to get away without a definition of smp_mb__release_acquire. > Fair enough, and plus there is actually no user(even potential user) of this for now, it may be too early to argue where the barrier should be put. Regards, Boqun signature.asc Description: PGP signature
RE: [PATCH v8 09/13] KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd'
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, September 16, 2015 5:27 PM
> To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org;
> mtosa...@redhat.com
> Cc: eric.au...@linaro.org; k...@vger.kernel.org;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v8 09/13] KVM: Add an arch specific hooks in 'struct
> kvm_kernel_irqfd'
>
>
>
> On 16/09/2015 10:50, Feng Wu wrote:
> > +int kvm_arch_update_irqfd_routing(struct kvm *kvm, unsigned int host_irq,
> > + uint32_t guest_irq, bool set)
> > +{
> > + return !kvm_x86_ops->update_pi_irte ? -EINVAL :
> > + kvm_x86_ops->update_pi_irte(kvm, host_irq, guest_irq, set);
> > +}
> > +
>
> Just use "if" here. No need to resend if this is the only comment.
I am sorry, I don't quite understand. Do you mean I don't need to include
this patch in v9? If so, what about other patches with your Reviewed-by?
Thanks,
Feng
>
> >
> > }
> > +int __attribute__((weak)) kvm_arch_update_irqfd_routing(
> > + struct kvm *kvm, unsigned
>
> Empty line after "}".
>
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to check how much data left to sync to disk at umount?
On Mon, Sep 07, 2015 at 01:29:33PM +0800, Jeff Chua wrote: > When umount a slow device such as an SD card, the command will take a > while to run depending on how much data is left to write to the > device. Is there way to check how much data is remaining waiting to > write to the device? $ grep "Dirty\|Writeback" /proc/meminfo And infer from that. -Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iommu-common: Do not try to deref a null iommu->lazy_flush() pointer when n < pool->hint
The check for invoking iommu->lazy_flush() from iommu_tbl_range_alloc()
has to be refactored so that we only call ->lazy_flush() if it is non-null.
Signed-off-by: Sowmini Varadhan
---
lib/iommu-common.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/iommu-common.c b/lib/iommu-common.c
index ff19f66..b1c93e9 100644
--- a/lib/iommu-common.c
+++ b/lib/iommu-common.c
@@ -21,8 +21,7 @@ staticDEFINE_PER_CPU(unsigned int, iommu_hash_common);
static inline bool need_flush(struct iommu_map_table *iommu)
{
- return (iommu->lazy_flush != NULL &&
- (iommu->flags & IOMMU_NEED_FLUSH) != 0);
+ return ((iommu->flags & IOMMU_NEED_FLUSH) != 0);
}
static inline void set_flush(struct iommu_map_table *iommu)
@@ -211,7 +210,8 @@ unsigned long iommu_tbl_range_alloc(struct device *dev,
goto bail;
}
}
- if (n < pool->hint || need_flush(iommu)) {
+ if (iommu->lazy_flush &&
+ (n < pool->hint || need_flush(iommu))) {
clear_flush(iommu);
iommu->lazy_flush(iommu);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] Staging: wilc1000: Use NULL instead of zero
Why not the second one? None of the line edited in first patch haven't changed after that. On Tue, Sep 15, 2015 at 7:24 PM, Greg KH wrote: > On Tue, Sep 15, 2015 at 03:04:58PM +0530, Ronit Halder wrote: >> This patch fixes the warning generated by sparse >> "Using plain integer as NULL pointer" by using NULL >> instead of zero. >> >> Signed-off-by: Ronit halder >> --- >> >> v2: added a new patch in this patch series to fix the NULL comparison style > > This patch, and the second one, do not apply to my tree anymore :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] memory pressure and sizing problem
On Thu, Sep 03, 2015 at 11:44:45AM -0400, Tejun Heo wrote: > Hello, > > It's bothering that we don't have a good mechanism to detect and > expose memory pressure and it doesn't seem to be for want of trying. > I've been thinking about it for several days and would like to find > out whether it makes sense. Not being a mm person, I'm likely > mistaken in a lot of details, if not the core concept. Please point > out whenever I wander into the lala land. > > > 1. Background > > AFAIK, there currently are two metrics in use. One is scan ratio - > how many pages are being scanned for reclaim per unit time. This is > what paces the different reclaimers. While it is related to memory > pressure, it involves enough of other factors to be useful as a > measure of pressure - e.g. a high-bandwidth streaming workload would > cause high scan ratio but can't be said to be under memory pressure. There are other places we generate memory pressure, too - some slab caches can generate more pressure than the page cache in various workloads. If we are going to have a "generic memory pressure" measurement then we need to include caches that have shrinkers to control their size > 2. Memory pressure and sizing problem > > Memory pressure sounds intuitive but isn't actually that well defined. > It's closely tied to answering the sizing problem - "how much memory > does a given workload need to run smoothly?" and answering that has > become more important with cgroup and containerization. > > Sizing is inherently tricky because mm only tracks a small portion of > all memory accesses. We can't tell "this process referenced this page > twice, 2mins and 18secs ago". Deciding whether a page is actively > used costs and we only track enough information to make reclaim work > reasonably. Consequently, it's impossible to tell the working set > size of a workload without subjecting it to memory reclaim. Right, that's why some subsystems have moved away from using the page cache for large scale caching - the single access bit is insufficient to express the relative reclaim priority of a given page. > Once a workload is subject to memory reclaim, we need a way to tell > whether it needs more memory and that measure can be called memory > pressure - a workload is under memory pressure if it needs more memory > to execute smoothly. More precisely, I think it can be defined as the > following. Define "smoothly". :) > 3. Memory pressure > > In a given amount of time, the proportion of time that the execution > duration of the workload has been lengthened due to lack of memory. > > I used "lengthened" instead of "delayed" because delays don't > necessarily indicate that the workload can benefit from more memory. > Consider the following execution pattern where '_' is idle and '+' is > running. Let's assume that each CPU burst is caused by receiving a > request over network. > > W0: ++++++ > > Let's say the workload now needs to fault in some memory during each > CPU burst - represented by 'm'. > > W1: +mm+__+mm+__+mm+__ > > While delays due to memory shortage have occurred, the duration of the > execution stayed the same. In terms of amount of work done, the > workload wouldn't have benefited from more memory. Now, consider the > following workload where 'i' represents direct IO from filesystem. > > W2: ++++++ > > If the workload experiences the same page faults, > > W3: +mm++mm++mm+ > > The entire workload has been lengthened by 6 slots or 25%. According > to the above definition, it's under 25% memory pressure. This is a > well-defined metric which doesn't depend on implementation details and > enables immediate intuitive understanding of the current state. What this misses is that the "direct IO" can generate significant memory pressure itself. e.g. it requires block allocation, and the metadata that needs to be scanned and modified for the allocation is not in memory. At this point, the *filesystem* has a memory demand spread across several caches and the heap, and can easily run to being tens of pages of memory being needed. IOWs, this filesystem memory demand can be significant to enable "smooth" performance, because if we have to fetch metadata from disk on every IO (because it's being reclaimed between IOs by other memory demand) we will cause the system to grind to a halt. This is one of the reasons XFS moved away from using the page cache to back it's metadata buffers - we have a tree structure that the reclaim algorithm has to be aware of... In my mind, the key issue here is that much of the filesystem memory demand cannot be accounted to a single process - internal metadata may be owned by the filesytem (e.g. free space btrees, dquots, etc) and is accessed and modified by any process that is using the filesytem. Hence trying to account and control the necessary filesystem working set using memory pressure calculated from a process basis is
[PATCH] gpio: mention in DT binding doc that -gpio is also supported
The GPIO DT binding doc mentions that GPIO are mapped by defining
a -gpios property in the consumer device's node but a -gpio
sufix is also supported after commit:
dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property names")
Update the DT binding documentation to match the implementation.
Signed-off-by: Javier Martinez Canillas
---
Hello,
The GPIO documentation was updated to mention that the -gpio sufix
is also supported in patch https://lkml.org/lkml/2015/9/1/117 that
already landed in Torvalds tree.
I now noticed that the DT binding also only mentions -gpios so I'm
posting this patch that adds -gpio to the DT binding documentation.
Best regards,
Javier
Documentation/devicetree/bindings/gpio/gpio.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 5788d5cf1252..8db8c7bb96c1 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -13,10 +13,10 @@ properties, each containing a 'gpio-list':
gpio-specifier : Array of #gpio-cells specifying specific gpio
(controller specific)
-GPIO properties should be named "[-]gpios", with being the purpose
-of this GPIO for the device. While a non-existent is considered valid
-for compatibility reasons (resolving to the "gpios" property), it is not
allowed
-for new bindings.
+GPIO properties should be named "[-]gpios" or "[-]gpio" with
+being the purpose of this GPIO for the device. While a non-existent is
+considered valid for compatibility reasons (resolving to the "gpios" property),
+it is not allowed for new bindings.
GPIO properties can contain one or more GPIO phandles, but only in exceptional
cases should they contain more than one. If your device uses several GPIOs with
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] prepare zbud to be used by zram as underlying allocator
On (09/16/15 13:48), Vitaly Wool wrote: > as a follow-up to my previous patchset, I decided to first prepare > zbud/zpool related patches and then have some testing rounds and > performance measurements for zram running over both, and come up > with improved/verified zram/zpool patches then. Hi, just a side note, I'm afraid this is not how it works. numbers go first, to justify the patch set. -ss > > So for now, here comes the zbud/zpool part. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Potential issue with GPIO/IRQ flags
On Wed, Sep 16, 2015 at 4:07 PM, Andrew F. Davis wrote: > Hello all, > > I've noticed that in a few DT bindings GPIO_ACTIVE_* defines are > incorrectly used as interrupt flags. GPIO_ACTIVE_*'s are defined > in: > > include/dt-bindings/gpio/gpio.h > > and are used to describe GPIO pins. IRQ types are defined in: > > include/dt-bindings/interrupt-controller/irq.h > > and are flags for IRQ pins. It is perfectly valid for the meaning of the field to be defined by the interrupt controller, and gpio interrupts could do something different. We've tried to standardize this though. > These seem to have been mixed up in a few places, take for example: > arch/arm/boot/dts/tegra124-jetson-tk1.dts. On line 1393 we see the > correct usage, but just before on line 1384 we see the issue. > GPIO_ACTIVE_HIGH is defined as 0, the same as IRQ_TYPE_NONE. If > this IRQ was not hard-coded with the correct edge in the driver > this would not work. What the author probably wanted was > IRQ_TYPE_LEVEL_HIGH. > > Now lets look at commit c21e678b256b, in this the IRQ flags did not > matter as the correct flag was hard-coded (IRQF_TRIGGER_LOW), this > patch moves this to the DT, but changed the flag to GPIO_ACTIVE_LOW > instead of the desired IRQ_TYPE_LEVEL_LOW. GPIO_ACTIVE_LOW is defined > as 1, or IRQ_TYPE_EDGE_RISING in IRQ flags, which is not the > equivalent to IRQF_TRIGGER_LOW the author was probably looking for. > > A quick grep (git grep "interrupt.*GPIO_ACTIVE_") shows several more > instances of this. I found this by using one of these files as an > example and giving myself a lot of problems, so I would like to fix > this before it spreads anymore. > > I have a couple of ideas of how to go at this, first would be to > just replace the incorrect flags with what was intended, but for > some of these I don't know what was intended and do not have the > board to test. > > My other solution would be to just change all instances of the GPIO > flags to their value corresponding IRQ flags: > > - interrupts = <11 GPIO_ACTIVE_LOW>; > + interrupts = <11 IRQ_TYPE_EDGE_RISING>; > > this would not make any functional change as the defines would > still evaluate to the same value, but would make it obvious where > a problem may be and that they should probably be checked and > corrected, maybe we could even put a comment after: > > - interrupts = <11 GPIO_ACTIVE_LOW>; > + interrupts = <11 IRQ_TYPE_EDGE_RISING>; // FIXME: Check IRQ type > > Well, what do you think? This seems fine. It is no less wrong. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 27/31] net/tipc: use kmemdup rather than duplicating its implementation
On 08/07/2015 03:59 PM, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Ying Xue
> ---
> net/tipc/server.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/tipc/server.c b/net/tipc/server.c
> index 922e04a..c187cad 100644
> --- a/net/tipc/server.c
> +++ b/net/tipc/server.c
> @@ -411,13 +411,12 @@ static struct outqueue_entry *tipc_alloc_entry(void
> *data, int len)
> if (!entry)
> return NULL;
>
> - buf = kmalloc(len, GFP_ATOMIC);
> + buf = kmemdup(data, len, GFP_ATOMIC);
> if (!buf) {
> kfree(entry);
> return NULL;
> }
>
> - memcpy(buf, data, len);
> entry->iov.iov_base = buf;
> entry->iov.iov_len = len;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NBD: Disconnect connection/kill NBD server cause kernel bug even kernel hang
Hi, Markus, I've experienced kernel bug and system hang regarding using nbd-client/server on the same machine. Kernel verison is v4.2. I know http://nbd.sourceforge.net/ said: "Please note that read-write nbd with client and server on the same machine is a bad idea: expect deadlock within seconds". But it's mentioned at http://thread.gmane.org/gmane.linux.kernel/869784 that NBD should be able to handle client/server on the same machine. The bug can be easily reproduce like this; truncate -s 1G nbd.vol mkfs.ext4 nbd.vol service nbd-server restart nbd-client localhost /dev/nbd0 -N nbd-vol mount /dev/ndb0 /mnt/tmp wget https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.2.tar.xz --limit-rate=100k pkill nbd-server Then the following would be triggered: [ 2886.348891] block nbd0: Attempted send on closed socket [ 2886.350579] blk_update_request: I/O error, dev nbd0, sector 1016 [ 2886.352210] EXT4-fs warning (device nbd0): htree_dirblock_to_tree:959: inode #2: lblock 0: comm ls: error -5 reading directory block [ 2886.352236] block nbd0: Attempted send on closed socket [ 2886.353646] blk_update_request: I/O error, dev nbd0, sector 524 [ 2886.355267] block nbd0: Attempted send on closed socket [ 2886.356665] blk_update_request: I/O error, dev nbd0, sector 526 [ 2886.358271] block nbd0: Attempted send on closed socket [ 2886.359654] blk_update_request: I/O error, dev nbd0, sector 528 [ 2886.361253] block nbd0: Attempted send on closed socket [ 2886.362597] blk_update_request: I/O error, dev nbd0, sector 530 [ 2886.364106] block nbd0: Attempted send on closed socket [ 2886.365400] blk_update_request: I/O error, dev nbd0, sector 532 [ 2886.366905] block nbd0: Attempted send on closed socket [ 2886.368205] blk_update_request: I/O error, dev nbd0, sector 534 [ 2886.369714] block nbd0: Attempted send on closed socket [ 2886.371025] blk_update_request: I/O error, dev nbd0, sector 536 [ 2886.372560] block nbd0: Attempted send on closed socket [ 2886.373871] blk_update_request: I/O error, dev nbd0, sector 538 [ 2886.375283] block nbd0: Attempted send on closed socket [ 2886.376504] blk_update_request: I/O error, dev nbd0, sector 540 ... [ 2886.405309] block nbd0: Attempted send on closed socket [ 2886.406440] EXT4-fs error (device nbd0): __ext4_get_inode_loc:3927: inode #2: block 261: comm ls: unable to read itable block [ 2886.408816] [ cut here ] [ 2886.409800] kernel BUG at fs/buffer.c:3025! [ 2886.409800] invalid opcode: [#1] SMP [ 2886.409800] Modules linked in: [ 2886.409800] CPU: 3 PID: 17137 Comm: ls Not tainted 4.2.0 #11 [ 2886.409800] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20150306_163512-brownie 04/01/2014 [ 2886.409800] task: 8800b8a5 ti: 8800b7b64000 task.ti: 8800b7b64000 [ 2886.409800] RIP: 0010:[] [] submit_bh_wbc+0x16e/0x180 [ 2886.409800] RSP: 0018:8800b7b67b58 EFLAGS: 00010246 [ 2886.409800] RAX: 0005 RBX: 8800adb849c0 RCX: [ 2886.409800] RDX: RSI: 8800adb849c0 RDI: 0411 [ 2886.409800] RBP: 8800b7b67b88 R08: fff0 R09: [ 2886.409800] R10: 0218 R11: 0006 R12: 0411 [ 2886.409800] R13: 8800b88fc400 R14: 0002facc R15: 88013a39 [ 2886.409800] FS: 7f83cf856840() GS:88013fd8() knlGS: [ 2886.409800] CS: 0010 DS: ES: CR0: 8005003b [ 2886.409800] CR2: 00f75388 CR3: 000139896000 CR4: 06e0 [ 2886.409800] Stack: [ 2886.409800] 88013a395358 8800adb849c0 0411 8800b88fc400 [ 2886.409800] 0002facc 88013a39 8800b7b67ba8 811a9449 [ 2886.409800] 81f209e0 8800adb849c0 8800b7b67bb8 811a94ee [ 2886.409800] Call Trace: [ 2886.409800] [] __sync_dirty_buffer+0x59/0xf0 [ 2886.409800] [] sync_dirty_buffer+0xe/0x10 [ 2886.409800] [] ext4_commit_super+0x181/0x200 [ 2886.409800] [] __ext4_error_inode+0x85/0x140 [ 2886.409800] [] __ext4_get_inode_loc+0x1fd/0x3d0 [ 2886.409800] [] ext4_get_inode_loc+0x18/0x20 [ 2886.409800] [] ext4_reserve_inode_write+0x1f/0x80 [ 2886.409800] [] ? ext4_dirty_inode+0x43/0x60 [ 2886.409800] [] ext4_mark_inode_dirty+0x48/0x1e0 [ 2886.409800] [] ext4_dirty_inode+0x43/0x60 [ 2886.409800] [] __mark_inode_dirty+0x163/0x310 [ 2886.409800] [] generic_update_time+0x72/0xc0 [ 2886.409800] [] ? current_fs_time+0x11/0x60 [ 2886.409800] [] touch_atime+0x83/0xa0 [ 2886.409800] [] iterate_dir+0xd6/0x120 [ 2886.409800] [] SyS_getdents+0x7c/0xe0 [ 2886.409800] [] ? fillonedir+0xc0/0xc0 [ 2886.409800] [] ? trace_do_page_fault+0x3c/0xb0 [ 2886.409800] [] entry_SYSCALL_64_fastpath+0x12/0x71 [ 2886.409800] Code: 09 e7 14 00 48 83 c4 08 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 40 f6 c7 01 0f 84 ff fe ff ff f0 80 63 01 f7 e9 f5 fe ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 55 31 c9 [
Re: [PATCH] clk: tegra: dfll: add missing rcu_read_unlock() for error path
On 09/17/2015 06:15 AM, Stephen Boyd wrote:
On 09/16, Vince Hsu wrote:
From: Vince Hsu
The commit e770940218028c6a5927fda45f2ca9db5d9b35e0 ("clk: tegra: dfll:
Properly protect OPP list") added the rcu_read_{lock,unlock} but missed
one in the error path. So add the missing one.
Signed-off-by: Vince Hsu
---
I think we'll just squash this into the original patch from
Thierry.
Sure. Thanks!
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
On Wed, Sep 16, 2015 at 5:37 PM, Dave Chinner wrote: > > TL;DR: Results look really bad - not only is the plugging > problematic, baseline writeback performance has regressed > significantly. Dave, if you're testing my current -git, the other performance issue might still be the spinlock thing. I haven't gotten the -tip pull fox the spinlock regression yet, and since you were the only one who noticed, I didn't consider it critical enough to bypass the normal schedule, so -rc1 still has the crazy-bad test-and-set loop for spinlocks. So it's waiting in the locking fix branch (and is cc'd for stable), but hasn't reached me yet. If you want to test that theory out, you can make virt_spin_lock() just unconditionally return false to disable the bad cmpxchg loop for now. The plugging IO pauses are interesting, though. Plugging really *shouldn't* cause that kind of pauses, _regardless_ of what level it happens on, so I wonder if the patch ends up just exposing some really basic problem that just normally goes hidden. Can you match up the IO wait times with just *where* it is waiting? Is it waiting for that inode I_SYNC thing in inode_sleep_on_writeback()? But it does sound like we should just revert the whole plugging for now, if only because "it has odd effects". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: configs: Add Freescale LS1021A defconfig
On Wed, Sep 16, 2015 at 08:22:56AM +, Huan Wang wrote: > Hi, Shawn, > > > On Fri, Aug 28, 2015 at 5:04 AM, Huan Wang > > wrote: > > > > > I need Fabio's confirmation about removing CONFIG_SOC_LS1021A from > > imx_v6_v7_config. > > > > > > Fabio, Do you agree it? > > > > Yes, if Shawn accepts ls1021a_defconfig then we should remove > > CONFIG_SOC_LS1021A from imx_v6_v7_config. > > > [Alison Wang] Could you help to review this patch? Can you please resend the patch with some explanation in the commit log on why we need a new defconfig, i.e. why imx_v6_v7_config doesn't work for LS1021A. Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel
On Mon, Sep 07, 2015 at 02:19:11PM +0530, maitysancha...@gmail.com wrote:
> Hi Shawn,
>
> On 15-09-06 12:32:32, Shawn Guo wrote:
> > On Thu, Aug 06, 2015 at 09:28:22PM +0530, Sanchayan Maity wrote:
> > > Add iio_hwmon node to expose the temperature channel on Vybrid
> > > as hardware monitor device using the iio_hwmon driver.
> > >
> > > Signed-off-by: Sanchayan Maity
> > > ---
> > > arch/arm/boot/dts/vfxxx.dtsi | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > > index 39173bb..0993d66 100644
> > > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > > @@ -597,5 +597,10 @@
> > > status = "disabled";
> > > };
> > > };
> > > +
> > > + iio_hwmon {
> >
> > Hyphen rather than underscore should be used in node name.
>
> As per iio-bindings.txt I did this. It is the same in imx23.dtsi and
> imx28.dtsi.
>
> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/iio-bindings.txt#L85
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx23.dtsi#L570
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx28.dtsi#L1246
Oh, sorry, all these should be caught earlier.
>
> So should this be changed?
Yeah, that would be nice, if the change doesn't break anything.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] locking/static_keys: fix a silly typo
On Tue, 08 Sep 2015 12:05:04 -0400 Jason Baron wrote: > > > On 09/07/2015 03:18 PM, Jonathan Corbet wrote: > > 412758cb2670 (jump label, locking/static_keys: Update docs) introduced a > > typo that might as well get fixed. > > > > Signed-off-by: Jonathan Corbet > > --- > > Documentation/static-keys.txt | 2 +- > > include/linux/jump_label.h| 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt > > index f4cb0b2..ec91158 100644 > > --- a/Documentation/static-keys.txt > > +++ b/Documentation/static-keys.txt > > @@ -16,7 +16,7 @@ The updated API replacements are: > > DEFINE_STATIC_KEY_TRUE(key); > > DEFINE_STATIC_KEY_FALSE(key); > > static_key_likely() > > -statick_key_unlikely() > > +static_key_unlikely() > > > > 0) Abstract > > > > diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h > > index 7f653e8..0684bd3 100644 > > --- a/include/linux/jump_label.h > > +++ b/include/linux/jump_label.h > > @@ -22,7 +22,7 @@ > > * DEFINE_STATIC_KEY_TRUE(key); > > * DEFINE_STATIC_KEY_FALSE(key); > > * static_key_likely() > > - * statick_key_unlikely() > > + * static_key_unlikely() > > * > > * Jump labels provide an interface to generate dynamic branches using > > * self-modifying code. Assuming toolchain and architecture support, if we > > > > Thanks. I actually messed this up further. That's supposed to be, > 'static_branch_likely()', and 'static_branch_unlikely()'. So: > > s/static_key_likely()/static_branch_likely() > > and > > s/static_key_unlikely()/static_branch_unlikely() > I sent a patch to fix that part on August 25: https://lkml.org/lkml/2015/8/25/288 Did I send it to the wrong person? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling.
Andy Lutomirski writes:
> On Wed, Sep 16, 2015 at 1:02 PM, Seth Forshee
> wrote:
>> From: "Eric W. Biederman"
>>
>> - Consolidate the testing if a device node may be opened in a new
>> function may_open_dev.
>>
>> - Move the check for allowing access to device nodes on filesystems
>> not mounted in the initial user namespace from mount time to open
>> time and include it in may_open_dev.
>>
>> This set of changes removes the implicit adding of MNT_NODEV which
>> simplifies the logic in fs/namespace.c and removes a potentially
>> problematic user visible difference in how normal and unprivileged
>> mount namespaces work.
>>
>> Signed-off-by: "Eric W. Biederman"
>
>> - /* Only in special cases allow devices from mounts
>> -* created outside the initial user namespace.
>> -*/
>> - if (!(type->fs_flags & FS_USERNS_DEV_MOUNT)) {
>> - flags |= MS_NODEV;
>> - mnt_flags |= MNT_NODEV | MNT_LOCK_NODEV;
>> - }
>
> This is an ABI change. It's probably okay, but I think the commit
> message should make it clear what's happening.
You mean it should include in big flashing neon letters
***REGRESSION FIX***
?
It is longer in coming than I had hoped. But that is part of the reason
I did not fix the security hole this way. Getting the s_user_ns stuff
just so has been non-trivial.
I do agree that because this is a user visible change we do need to keep
our eyes peeled for pieces of userspace software that may depend on the
exact details of the current behavior.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH 5/7] f2fs: enhance multithread dio write performance
On 2015/9/16 18:15, Chao Yu wrote:
Hi Jaegeuk,
-Original Message-
From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
Sent: Wednesday, September 16, 2015 5:21 AM
To: Chao Yu
Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/7] f2fs: enhance multithread dio write performance
Hi Chao,
On Fri, Sep 11, 2015 at 02:41:53PM +0800, Chao Yu wrote:
When dio writes perform concurrently, our performace will be low because of
Thread A's allocation of multi continuous blocks will be break by Thread B,
there are two cases as below:
- In Thread B, we may change current segment to a new segment for LFS
allocation if we dio write in the beginning of the file.
- In Thread B, we may allocate blocks in the middle of Thread A's
allocation, which make blocks which allocated in Thread A being
discontinuous.
This patch adds writepages mutex lock to make block allocation in dio write
atomic to avoid above issues.
Test environment:
ubuntu os with linux kernel 4.2+, intel i7-3770, 16g memory,
32g kingston sd card.
fio --name seqw --ioengine=sync --invalidate=1 --rw=write --directory=/mnt/f2fs
--filesize=256m --size=16m --bs=2m --direct=1
--numjobs=10
before:
WRITE: io=163840KB, aggrb=3145KB/s, minb=314KB/s, maxb=411KB/s,
mint=39836msec,
maxt=52083msec
patched:
WRITE: io=163840KB, aggrb=10033KB/s, minb=1003KB/s, maxb=1124KB/s,
mint=14565msec,
maxt=16329msec
Signed-off-by: Chao Yu
---
fs/f2fs/data.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index a737ca5..a0a5849 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1536,7 +1536,9 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct
iov_iter *iter,
struct file *file = iocb->ki_filp;
struct address_space *mapping = file->f_mapping;
struct inode *inode = mapping->host;
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
size_t count = iov_iter_count(iter);
+ int rw = iov_iter_rw(iter);
int err;
/* we don't need to use inline_data strictly */
@@ -1555,12 +1557,17 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb,
struct iov_iter
*iter,
trace_f2fs_direct_IO_enter(inode, offset, count, iov_iter_rw(iter));
- if (iov_iter_rw(iter) == WRITE)
+ if (rw == WRITE) {
+ mutex_lock(>writepages);
Why do we have to share sbi->writepages?
The root cause of this issue is that: in f2fs, we have no suitable
dispatcher which can do the following things as an atomic operation:
a) allocate position(s) in flash device for current block(s);
b) submit user data in allocated position(s) in block layer.
Without the dispatcher, we will suffer performance issue in following
scenario:
Thread AThread BThread C
allocate pos+1
allocate pos+2
allocate pos+3
submit pos+1
submit pos+3
submit pos+2
Our final submitting series will: pos+1, pos+3, pos+2, this makes f2fs
running into non-LFS mode, therefore resulting in bad performance.
writepages mutex lock supply us with a good solution for above issue.
It not only make the allocating and submitting pair executing atomically,
but also reduce the fragmentation for one file since we submit blocks
belong to single inode as continuous as possible.
So here I choose to use writepages mutex lock to fix the performance
issue caused by both dio write vs dio write and dio write vs buffered
write.
If I'm missing something, please correct me.
__allocate_data_blocks(inode, offset, count);
If the problem lies on the misaligned blocks, how about calling mutex_unlock
here?
When changing to unlock here, I got regression when testing with following
command:
fio --name seqw --ioengine=sync --invalidate=1 --rw=write --directory=/mnt/f2fs
--filesize=256m --size=4m --bs=64k --direct=1
--numjobs=20
unlock here:
WRITE: io=81920KB, aggrb=5802KB/s, minb=290KB/s, maxb=292KB/s,
mint=14010msec, maxt=14119msec
unlock after dio finished:
WRITE: io=81920KB, aggrb=6088KB/s, minb=304KB/s, maxb=1081KB/s,
mint=3786msec, maxt=13454msec
So how about keep it in original place in this patch?
Does share writepages mutex lock have an effect on cache write? Here is
AndroBench result on my phone:
Before patch:
1R1W 8R8W 16R16W
Sequential Write 161.31 163.85 154.67
Random Write 9.48 17.66 18.09
After patch:
1R1W 8R8W 16R16W
Sequential Write 159.61 157.24 160.11
Random Write 9.17 8.518.8
Unit:Mb/s, File size: 64M, Buffer size: 4k
Thanks,
Re: [PATCH] fs-writeback: drop wb->list_lock during blk_finish_plug()
[cc Tejun] On Thu, Sep 17, 2015 at 08:07:04AM +1000, Dave Chinner wrote: > On Wed, Sep 16, 2015 at 04:00:12PM -0400, Chris Mason wrote: > > On Wed, Sep 16, 2015 at 09:58:06PM +0200, Jan Kara wrote: > > > On Wed 16-09-15 11:16:21, Chris Mason wrote: > > > > Short version, Linus' patch still gives bigger IOs and similar perf to > > > > Dave's original. I should have done the blktrace runs for 60 seconds > > > > instead of 30, I suspect that would even out the average sizes between > > > > the three patches. > > > > > > Thanks for the data Chris. So I guess we are fine with what's currently > > > in, > > > right? > > > > Looks like it works well to me. > > Graph looks good, though I'll confirm it on my test rig once I get > out from under the pile of email and other stuff that is queued up > after being away for a week... I ran some tests in the background while reading other email. TL;DR: Results look really bad - not only is the plugging problematic, baseline writeback performance has regressed significantly. We need to revert the plugging changes until the underlying writeback performance regressions are sorted out. In more detail, these tests were run on my usual 16p/16GB RAM performance test VM with storage set up as described here: http://permalink.gmane.org/gmane.linux.kernel/1768786 The test: $ ~/tests/fsmark-10-4-test-xfs.sh meta-data=/dev/vdc isize=512agcount=500, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=1 = crc=1finobt=1, sparse=0 data = bsize=4096 blocks=134217727500, imaxpct=1 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=131072, version=2 = sectsz=512 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # ./fs_mark -D 1 -S0 -n 1 -s 4096 -L 120 -d /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/2 -d /mnt/scratch/3 -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 -d /mnt/scratch/7 # Version 3.3, 8 thread(s) starting at Thu Sep 17 08:08:36 2015 # Sync method: NO SYNC: Test does not issue sync() or fsync() calls. # Directories: Time based hash between directories across 1 subdirectories with 180 seconds per subdirectory. # File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name) # Files info: size 4096 bytes, written with an IO size of 16384 bytes per write # App overhead is time in microseconds spent in the test not doing file writing related system calls. FSUse%Count SizeFiles/sec App Overhead 08 4096 106938.0 543310 0 16 4096 102922.7 476362 0 24 4096 107182.9 538206 0 32 4096 107871.7 619821 0 40 4096 99255.6 622021 0 48 4096 103217.8 609943 0 56 4096 96544.2 640988 0 64 4096 100347.3 676237 0 72 4096 87534.8 483495 0 80 4096 72577.5 2556920 0 88 4096 97569.0 646996 0 96 4096 80147.0 515679 0 104 4096 100394.2 816979 0 112 4096 91466.5 739009 0 120 4096 85868.1 977506 0 128 4096 89691.5 715207 0 136 4096 52547.5 712810 0 144 4096 47999.1 685282 0 152 4096 47894.3 697261 0 160 4096 47549.4 789977 0 168 4096 40029.2 677885 0 176 4096 16637.4 12804557 0 184 4096 16883.6 24295975 0 192 4096 18852.1 22264137 0 200 4096 27107.3 10310408 0 208 4096 23654.1 19823567 0 216 4096 24588.9 19769484 0 224 4096 13959.3 40168163 0 232 4096 26239.2 17806813 0 240 4096 17858.5 24596715 0 248 4096 12072.9 38177650 0 256 4096 9989.7 43413729 0 688 4096 11773.4 16470400 0 696 4096 5556.5 27325343
Re: [PATCH] configfs: Implement binary attributes
Hi Pantelis, can you check if your patches become simpler on top of the changes in this tree: http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/configfs.2 I recently started using configfs and came up with this to avoid the gigantic amounts of boilerplate code required for configfs attributes at the moment. I plan to send it out soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
Hi Jiri,
On Wed, 16 Sep 2015 08:16:52 +0200 Jiri Olsa wrote:
>
> On Wed, Sep 16, 2015 at 10:12:45AM +1000, Stephen Rothwell wrote:
> >
> > After merging the tip tree, today's linux-next build (perf) failed
> > like this:
> >
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by
> > 'tools/perf/arch/common.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'arch' failed
> > make[4]: *** No rule to make target 'fs/debugfs.h', needed by
> > 'tools/perf/fs/fs.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'fs' failed
> > make[3]: *** No rule to make target 'tools/lib/api/fs/debugfs.h', needed by
> > 'tools/perf/util/abspath.o'. Stop.
> > tools/build/Makefile.build:109: recipe for target 'util' failed
> > Makefile:32: recipe for target 'tools/perf/libapi-in.o' failed
> > Makefile.perf:417: recipe for target 'tools/perf/libapi.a' failed
> > Makefile.perf:393: recipe for target 'tools/perf/libperf-in.o' failed
> > Makefile:68: recipe for target 'all' failed
> >
> > Maybe caused by commit
> >
> > 60a1133a5b39 ("tools lib api fs: Remove debugfs, tracefs and findfs
> > objects")
> >
> > This is an incremental build i.e. I do not do a "make clean" after doing
> > the build for each tree merge (in case that matters).
>
> it does in this case, removed header files stay in
> cmd build dependency file (like in .abspath.o.cmd above)
> and cause build error
>
> build system is not smart enough yet to find out,
> I was postponning fixing this for some time now,
> I'll try to get this resolved asap
OK, for now I will clean out my objdir before doing the perf build
after the tip tree merge. It would be nice to have this fixed, though,
if possible.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] PCI/MSI: X-Gene: Remove msi_controller assignment in X-Gene PCIe driver
With commit 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of
struct msi_controller"), it is no longer required to assign
msi_controller for X-Gene PCIe host bridge to support MSI. This
patch removes this unnecessary code and also helps avoid a warning
message ("failed to enable MSI") during boot.
Signed-off-by: Duc Dang
Cc: Tanmay Inamdar
---
drivers/pci/host/pci-xgene.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0236ab9..ae00ce2 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -509,24 +509,6 @@ static int xgene_pcie_setup(struct xgene_pcie_port *port,
return 0;
}
-static int xgene_pcie_msi_enable(struct pci_bus *bus)
-{
- struct device_node *msi_node;
-
- msi_node = of_parse_phandle(bus->dev.of_node,
- "msi-parent", 0);
- if (!msi_node)
- return -ENODEV;
-
- bus->msi = of_pci_find_msi_chip_by_node(msi_node);
- if (!bus->msi)
- return -ENODEV;
-
- of_node_put(msi_node);
- bus->msi->dev = >dev;
- return 0;
-}
-
static int xgene_pcie_probe_bridge(struct platform_device *pdev)
{
struct device_node *dn = pdev->dev.of_node;
@@ -567,10 +549,6 @@ static int xgene_pcie_probe_bridge(struct platform_device
*pdev)
if (!bus)
return -ENOMEM;
- if (IS_ENABLED(CONFIG_PCI_MSI))
- if (xgene_pcie_msi_enable(bus))
- dev_info(port->dev, "failed to enable MSI\n");
-
pci_scan_child_bus(bus);
pci_assign_unassigned_bus_resources(bus);
pci_bus_add_devices(bus);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers
The remoteproc core uses a static ida named rproc_dev_index for
assigning an automatic index number to a registered remoteproc.
The ida core may allocate some internal idr cache layers and ida
bitmap upon any ida allocation, and all these layers are truely
freed only upon the ida destruction. The rproc_dev_index ida is
not destroyed at present, leading to a memory leak when using the
remoteproc core as a module and atleast one rproc device is
registered and unregistered.
Fix this by invoking ida_destroy() in the remoteproc core module
exit.
Cc: Ohad Ben-Cohen
Signed-off-by: Suman Anna
---
drivers/remoteproc/remoteproc_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 8b3130f22b42..9e03d158f411 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1478,6 +1478,8 @@ module_init(remoteproc_init);
static void __exit remoteproc_exit(void)
{
+ ida_destroy(_dev_index);
+
rproc_exit_debugfs();
}
module_exit(remoteproc_exit);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Fix memory leaks in virtio & remoteproc cores
Hi, The following patches fix couple of memory leaks in the virtio and remoteproc cores when using these as modules, and going through a cycle of insmod and rmmod with at least a device registered with the corresponding cores in between. I ran into this on our downstream product kernels on both 3.14 and 4.1 based kernels, and should apply to the latest kernel as well. Patches can be picked up independently through the respective trees. regards Suman Suman Anna (2): virtio: fix memory leak of virtio ida cache layers remoteproc: fix memory leak of remoteproc ida cache layers drivers/remoteproc/remoteproc_core.c | 2 ++ drivers/virtio/virtio.c | 1 + 2 files changed, 3 insertions(+) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] virtio: fix memory leak of virtio ida cache layers
The virtio core uses a static ida named virtio_index_ida for
assigning index numbers to virtio devices during registration.
The ida core may allocate some internal idr cache layers and
an ida bitmap upon any ida allocation, and all these layers are
truely freed only upon the ida destruction. The virtio_index_ida
is not destroyed at present, leading to a memory leak when using
the virtio core as a module and atleast one virtio device is
registered and unregistered.
Fix this by invoking ida_destroy() in the virtio core module
exit.
Cc: "Michael S. Tsirkin"
Signed-off-by: Suman Anna
---
drivers/virtio/virtio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index b1877d73fa56..7062bb0975a5 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -412,6 +412,7 @@ static int virtio_init(void)
static void __exit virtio_exit(void)
{
bus_unregister(_bus);
+ ida_destroy(_index_ida);
}
core_initcall(virtio_init);
module_exit(virtio_exit);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Ensure proper suspend/resume ordering
On Wednesday, September 16, 2015 04:38:07 PM Grygorii Strashko wrote: > On 09/16/2015 04:18 AM, Rafael J. Wysocki wrote: > > On Tuesday, September 15, 2015 05:53:02 PM Thierry Reding wrote: [cut] > > > > > Did that patch manipulate dpm_list? > > no. So whether or not there were any problems with it is meaningless here. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] userns: Simpilify MNT_NODEV handling.
On Wed, Sep 16, 2015 at 1:02 PM, Seth Forshee
wrote:
> From: "Eric W. Biederman"
>
> - Consolidate the testing if a device node may be opened in a new
> function may_open_dev.
>
> - Move the check for allowing access to device nodes on filesystems
> not mounted in the initial user namespace from mount time to open
> time and include it in may_open_dev.
>
> This set of changes removes the implicit adding of MNT_NODEV which
> simplifies the logic in fs/namespace.c and removes a potentially
> problematic user visible difference in how normal and unprivileged
> mount namespaces work.
>
> Signed-off-by: "Eric W. Biederman"
> - /* Only in special cases allow devices from mounts
> -* created outside the initial user namespace.
> -*/
> - if (!(type->fs_flags & FS_USERNS_DEV_MOUNT)) {
> - flags |= MS_NODEV;
> - mnt_flags |= MNT_NODEV | MNT_LOCK_NODEV;
> - }
This is an ABI change. It's probably okay, but I think the commit
message should make it clear what's happening.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Failover root devices
I would like to see Linux support multiple root devices, so that it can attempt one and move on to the next if it is not present. I've reviewed the relevant code during boot-up and it seems like a good place for me to submit my first patch, but I want to bring it up for discussion here on LKML first. The design I had in mind is something like this: root=device;device;device;... Where 'device' follows the current format (/dev/sdX, UUIDs, and so on, via name_to_dev_t). I would modify prepare_namespace to iterate through each offered root device until one works. My use-case for this feature is that I would like to be able to change the hardware of my machine and boot up differently based on what's present. In my case, I would like to install my system normally, with /boot on its own partition, and keep a seperate userspace on a flash drive. Then, during boot-up, if the flash drive is present, it would be used as the root device. If it's not present, a partition on disk would be selected. The only potential roadblock with this feature that comes to mind is figuring out how to handle time-outs between root devices. I think it would be wise to choose a sensible default value, and provide another cmdline parameter to tweak it. The prepare_namespace flow might end up looking something like this: 1. Wait rootdelay seconds 2. Check 1st device, not present 3. Recheck 1st device until rootfailoverdelay seconds has passed 4. Move on to 2nd device, present -> boot Or: 1. Wait rootdelay seconds 2. Check 1st device, not present 3. Recheck 1st device until rootfailoverdelay seconds has passed 4. Move on to 2nd device, not present 5. Recheck 2st device until rootfailoverdelay seconds has passed 6. GOTO 2 And so on. I also need to research how the various init systems interact with this part of the boot process. I suspect systemd probably does something silly wrt waiting for the root device. Since this feature would (of course) be backwards compatible, it might be wise to just implement it here and let the init systems add support for the feature themselves. Advice? Who should I send my patches to when they're ready? Please CC me, I do not subscribe to LKML. -- Drew DeVault -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage
On Wednesday, September 16, 2015 04:45:51 PM George McCollister wrote: > Unfortunately I just got around to trying linux 4.1.6 (which contains > this commit) on the Versalogic Tiger (VL-EPM-24) > http://www.versalogic.com/tiger and this commit breaks it, seems to be > back to the old behavior reported here: > > http://marc.info/?t=14309238462=1=2 > > Before reversing the commit it shows: > pci :00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] > > After reversing the commit it shows: > pci :00:1c.0: BAR 13: assigned [io 0x3000-0x3fff] > > I don't have a solution to propose at this point and haven't tried the > latest upstream so I'll just be building with this commit reversed > (which solves the problem) until I have a chance to look into this > further. It looks like on your system the ACPI resources really need to be reserved before the PCI bus is initialized, but we can't do that unconditionally for everyone without introducing regressions, so the only way to address that I can see would be to blacklist your system. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_irq.c
between commit:
4e3d1e26c2b2 ("drm/i915: Pass hpd_status_i915[] to intel_get_hpd_pins() in
pre-g4x")
from Linus' tree and commit:
58f2cf241fb9 ("drm/i915: Don't call intel_get_hpd_pins() when there's no
hotplug interrupt")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_irq.c
index 5a244ab9395b,ca6d806a195a..
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@@ -1557,10 -1652,13 +1652,13 @@@ static void i9xx_hpd_irq_handler(struc
} else {
u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
- intel_get_hpd_pins(_mask, _mask, hotplug_trigger,
- hotplug_trigger, hpd_status_i915,
- i9xx_port_hotplug_long_detect);
- intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ if (hotplug_trigger) {
+ intel_get_hpd_pins(_mask, _mask,
hotplug_trigger,
- hotplug_trigger, hpd_status_g4x,
++ hotplug_trigger, hpd_status_i915,
+ i9xx_port_hotplug_long_detect);
+
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] ACPI: Provide better MADT subtable sanity checks
On Wednesday, September 16, 2015 10:27:57 AM Al Stone wrote: > On 09/16/2015 10:24 AM, Al Stone wrote: > > On 09/15/2015 08:44 PM, Rafael J. Wysocki wrote: > >> On Tuesday, September 15, 2015 03:13:12 PM Al Stone wrote: > >>> On 09/09/2015 03:09 PM, Al Stone wrote: > Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity > check on the various subtables that are defined for the MADT. The check > compares the size of the subtable data structure as defined by ACPICA to > the length entry in the subtable. If they are not the same, the > assumption > is that the subtable is incorrect. > > > [snip...] > > >> I'm going to apply this series if people have no problems with it. I do > >> think > >> it is slightly overkill, but then as long as it works ... > >> > >> Thanks, > >> Rafael > >> > > Would you prefer I send out the updated version with Sudeep's fix to apply > instead of this version? Yes, I would. > Or have you picked that up already? No, I haven't. > Easily updated and sent out, if it'll make your life simpler Yes, please. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
* Roger Quadros [150915 03:46]: > Tony, > > On 03/09/15 10:36, Roger Quadros wrote: > > Chanwoo, > > > > On 06/08/15 02:36, Chanwoo Choi wrote: > >> On 08/05/2015 07:37 PM, Tony Lindgren wrote: > >>> * Roger Quadros [150727 06:13]: > The VBUS line of USB2 is connected to VBUS detect logic on > the PMIC. Use the palmas-usb driver to report VBUS events > to the USB driver. > > As the palmas-usb driver supports GPIO based ID reporting > provide the GPIO for ID pin as well. > > Signed-off-by: Roger Quadros > >>> > >>> This should not cause merge conflicts with what I have queeud > >>> for v4.3, so Chanwoo please feel free to apply with the rest > >>> of the extcon series: > >>> > >>> Acked-by: Tony Lindgren > >>> > >>, > >> I reviewd this patchset related to extcon and give the acked-by message. > >> but patch1 must need the acked-by message from MFD maintainer. > >> > >> If patch1 receive the acked-by message from MFD maintainer, > >> I'll apply it for v4.3. > >> > >> Roger, > >> I think that you better to recevie the acked-by message before v4.2-rc6 > >> release. > >> I have the plan about pull request of extcon for v4.3 after v4.2-rc6 > >> releas. > > > > Seems like you picked patch 1 but not this one. As Tony has already Acked it > > can you please include patch 2 as well in your tree for -next? Thanks. > > > > Is it possible for you to pick this up for -rc cycle via omap-soc tree? > Thanks. OK picking up the second patch into omap-for-v4.3/fixes thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Fix gfp flags for coherent DMA memory allocation
On Mon, Sep 14, 2015 at 07:38:36AM +, Junichi Nomura wrote: > Commit 6894258eda2f reversed the order of gfp_flags adjustment in > dma_alloc_attrs() for x86 [arch/x86/kernel/pci-dma.c] > As a result, relevant flags set by dma_alloc_coherent_gfp_flags() > is just discarded and causes coherent DMA memory allocation failure > on some devices. Oops, sorry. Thanks for fixing this: Acked-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Ensure proper suspend/resume ordering
On Wednesday, September 16, 2015 03:22:37 PM Alan Stern wrote: > On Wed, 16 Sep 2015, Thierry Reding wrote: > > > > > Perhaps moving to the end of the list needs to be a little smarter. That > > > > is it could check whether the device has been prepared for suspension or > > > > not and only move when it hasn't? > > > > > > Maybe. But doesn't that mean it won't solve your problem completely? > > > > It would solve the problem completely if probing was prohibited during > > the suspend/resume cycle. But if that were true there'd be no need to > > special-case in the first place. > > It's possible that this approach will help. We'll see. > > It would also help if your patch checked to see if the device has any > children, and avoided moving it to the end of the list if it does. In > fact, that might be sufficient to avoid almost all problems. I agree. In any case if a device that already has children is about to be probed, this is sort of a corner case anyway and should be handled as such. > > > > Then again, shouldn't the core even prohibit new probes once the suspend > > > > has been triggered? Sounds like asking for a lot of trouble if it didn't > > > > ... > > > > > > The core prohibits new devices from being registered. It does not > > > prohibit probes of existing devices, because they currently do not > > > affect the dpm_list. > > > > My understanding was that the core was guaranteed not to call suspend or > > resume callbacks for devices that haven't completed probe. > > No, that's not so. The core invokes suspend and resume callbacks for > all registered devices. And those may be bus type callbacks that decide whether or not to call driver callbacks. Having a driver bound to a device is not necessary for a bus type callback to succeed in general. > > At least I've > > never seen any driver code specifically check in their suspend or resume > > callbacks that they've been probed successfully. > > Now that wouldn't make any sense, would it? A driver's suspend or > resume callback wouldn't be invoked in the first place unless the > driver had already been probed for that device. So there's no point in > checking whether the probe has occurred. > > > Allowing probes while a > > suspend is happening sounds racy. > > Yes, it does. It definitely isn't a good idea. > > During a sleep transition all user threads are frozen. So are some > kernel threads, but not all of them. It's possible that one of the > running kernel threads might want to do a probe -- something in a > workqueue, for example. That's the only way it could happen. A hotplug event or something like that I suppose, but those should be deferred to post resume time too. > > > In general, we rely on subsystems not to do any probing once a device > > > is suspended. It's probably reasonable to ask them not to do any > > > probing once a device has gone through the "prepare" stage. > > > > Perhaps the reason why we seem to be talking across purposes is that I > > haven't thought much about devices where the bus does all the heavy > > lifting. So suspending the device from a bus' perspective makes sense > > even if the device hasn't been bound. > > Yes. Precisely. > > And yes, I agree that preventing a probe for a device that has been > > prepared for suspension sounds like a very reasonable thing to do. > > > > > > > There's also an issue about other types of dependencies. For > > > > > instance, > > > > > it's conceivable that device B might be discovered and depend on > > > > > device > > > > > A, even before A has been bound to a driver. (B might be discovered > > > > > by > > > > > A's subsystem rather than A's driver.) In that case, moving A to the > > > > > end of the list would cause B to come before A even though B depends > > > > > on > > > > > A. Of course, deferred probing already has this problem. > > > > > > > > But that's exactly the problem that I'm seeing. > > > > > > Not quite. > > > > > > > B isn't discovered by > > > > A's subsystem, but the type of dependency is the same. A in this case > > > > would be the GPIO controller and B the gpio-keys device. B clearly > > > > depends on A, but deferred probe currently moves A to the end of the > > > > list but not A, hence why the problem occurs. > > > > > > The difference is that in my example, B can be probed before A. In > > > your case it can't. Therefore the patch works for your case but not > > > for mine. > > > > How would that even work in practice? Essentially you have a dependency > > between two devices and no way of guaranteeing any ordering. Either the > > dependency is completely optional, in which case the ordering of the > > dpm_list must be irrelevant to the interaction, or the drivers make too > > many assumptions and it is only working by accident. > > Rafael gave a good example. A device behind a PCIe port can't be > detected until the port has been registered, so the port will always > get on the
Re: [PATCH] ARM: dts: am57xx-beagle-x15: Update Phy supplies
* Nishanth Menon [150916 08:15]: > Hi Tony, > > On 09/03/2015 02:23 PM, Nishanth Menon wrote: > > Originally, all the SoC PHY rails were supplied by LDO3. However, as a > > result of characterization, it was determined that this posed a risk in > > extreme load conditions. Hence the PHY rails are split between two > > different LDOs. Update the related node as a result > > > > LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3 > > LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie > > > > NOTE: We break compatibility with pre-production boards with this change > > since, the PMIC LDO4 is disabled at OTP level. > > > > The new configuration is the plan of record and all pre-production > > boards are supposed to be replaced with the latest boards matching the > > mentioned configuration. > > > > Signed-off-by: Nishanth Menon > > --- > > Gentle ping. Some very few 10 something boards have been created and > stopped production till the latest modifications were done (PMIC USB > interrupt, LDO4 etc) - and all of those boards are now getting > scrapped.. If there are any (as per tracking information, there should > not be any), TI should be contacted to have them replaced. Sounds OK to me as they are TI internal protos. > Is it possible for us to consider this patch in 4.3 cycle - given that > we are this close, might have been great to see 4.3 vanilla function on > the production platform. Applying into omap-for-v4.3/fixes thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
> -Original Message-
> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> Sent: Wednesday, September 16, 2015 4:49 PM
> To: KY Srinivasan ; David Laight
> ; Haiyang Zhang ;
> Vitaly Kuznetsov ; net...@vger.kernel.org
> Cc: David S. Miller ; linux-kernel@vger.kernel.org;
> Jason Wang
> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V
>
> On 09/16/2015 03:57 PM, KY Srinivasan wrote:
> >
> >> -Original Message-
> >> From: Alexander Duyck [mailto:alexander.du...@gmail.com]
> >> Sent: Wednesday, September 16, 2015 2:39 PM
> >> To: KY Srinivasan ; David Laight
> >> ; Haiyang Zhang ;
> >> Vitaly Kuznetsov ; net...@vger.kernel.org
> >> Cc: David S. Miller ; linux-kernel@vger.kernel.org;
> >> Jason Wang
> >> Subject: Re: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-
> V
> >>
> >> On 09/16/2015 10:55 AM, KY Srinivasan wrote:
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Wednesday, September 16, 2015 9:25 AM
> To: Haiyang Zhang ; Vitaly Kuznetsov
> ; net...@vger.kernel.org
> Cc: David S. Miller ; linux-
> ker...@vger.kernel.org;
> KY Srinivasan ; Jason Wang
>
> Subject: RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for
> Hyper-
> V
>
> From: Haiyang Zhang
> > Sent: 16 September 2015 17:09
> >> -Original Message-
> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >> Sent: Wednesday, September 16, 2015 11:50 AM
> >> To: net...@vger.kernel.org
> >> Cc: David S. Miller ; linux-
> ker...@vger.kernel.org;
> >> KY Srinivasan ; Haiyang Zhang
> >> ; Jason Wang
> >> Subject: [PATCH net-next RFC] net: increase LL_MAX_HEADER for
> Hyper-
> V
> >> Commit b08cc79155fc26d0d112b1470d1ece5034651a4b
> ("hv_netvsc:
> Eliminate
> >>memory allocation in the packet send path") introduced skb
> headroom
> >> request for Hyper-V netvsc driver:
> >>
> >> max_needed_headroom = sizeof(struct hv_netvsc_packet) +
> >> sizeof(struct rndis_message) +
> >> NDIS_VLAN_PPI_SIZE +
> >> NDIS_CSUM_PPI_SIZE +
> >> NDIS_LSO_PPI_SIZE +
> >> NDIS_HASH_PPI_SIZE;
> >> ...
> >> net->needed_headroom = max_needed_headroom;
> >>
> >> max_needed_headroom is 220 bytes, it significantly exceeds the
> >> LL_MAX_HEADER setting. This causes each skb to be cloned on send
> path,
> >> e.g. for IPv4 case we fall into the following clause
> >> (ip_finish_output2()):
> >>
> >> if (unlikely(skb_headroom(skb) < hh_len && dev->header_ops)) {
> >> ...
> >> skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev));
> >> ...
> >> }
> >>
> >> leading to a significant performance regression. Increase
> LL_MAX_HEADER
> >> to make it suitable for netvsc, make it 224 to be 16-aligned.
> >> Alternatively we could (partially) revert the commit which introduced
> >> skb
> >> headroom request restoring manual memory allocation on transmit
> path.
> >>
> >> Signed-off-by: Vitaly Kuznetsov
> >> ---
> >>include/linux/netdevice.h | 4 +++-
> >>1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> index 88a0069..7233790 100644
> >> --- a/include/linux/netdevice.h
> >> +++ b/include/linux/netdevice.h
> >> @@ -132,7 +132,9 @@ static inline bool dev_xmit_complete(int rc)
> >> * used.
> >> */
> >>
> >> -#if defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> >> +#if IS_ENABLED(CONFIG_HYPERV_NET)
> >> +# define LL_MAX_HEADER 224
> >> +#elif defined(CONFIG_WLAN) || IS_ENABLED(CONFIG_AX25)
> >># if defined(CONFIG_MAC80211_MESH)
> >># define LL_MAX_HEADER 128
> >># else
> > Thanks for the patch.
> > To avoid we forget to update that 224 number when we add more things
> > into netvsc header, I suggest that we define a macro in netdevice.h such
> > as:
> > #define HVNETVSC_MAX_HEADER 224
> > #define LL_MAX_HEADER HVNETVSC_MAX_HEADER
> >
> > And, put a note in netvsc code saying the header reservation shouldn't
> > exceed HVNETVSC_MAX_HEADER, or you need to update
> HVNETVSC_MAX_HEADER.
>
> Am I right in thinking this is adding an extra 96 unused bytes to the
> front
> of almost all skb just so that hyper-v can make its link level header
> contiguous with whatever follows (IP header ?).
>
> Doesn't sound ideal.
> >>> Remote NDIS is the protocol used to send packets from the guest to the
> host.
> >> Every packet
> >>> needs to be decorated with the RNDIS header and the maximum room
> needed
> >> for the RNDIS
> >>> header is the
RE: [PATCH v2] futex: lower the lock contention on the HB lock during wake up
> On Wed, 16 Sep 2015, Zhu Jefferry wrote: > > > > The primary debugging shows the content of __lock is wrong in first. > > > > After a call of Mutex_unlock, the value of __lock should not be > > > > this thread self. But we observed The value of __lock is still > > > > self after unlock. So, other threads will be stuck, > > > > > > How did you observe that? > > > > Add one assert in mutex_unlock, after it finish the __lock modify > > either in User space or kernel space, before return. > > And that assert tells you that the kernel screwed up the futex value? > No, it does not. It merily tells you that the value is not what you > expect, but it does not tell you what caused that. > > Hint: There are proper instrumentation tools, e.g. tracing, which tell > you the exact flow of events and not just the observation after the fact. I'm trying to get more details about the failure flow. But I'm told a little Bit timing changing in the code might impact the failure appear in a longer time, or even disappear. > > > > > This thread could lock due to recursive type and __counter keep > > > > increasing, although mutex_unlock return fails, due to the wrong > > > > value of __owner, but the application did not check the return > > > > value. So the thread 0 looks like fine. But thread 1 will be stuck > forever. > > > > > > Oh well. So thread 0 looks all fine, despite not checking return > values. > > > > > > > Correct. > > No. That's absolutely NOT correct. Not checking return values can cause > all kind of corruptions. Return values are there for a reason. > Besides the application did not check the return value, the mutex_unlock in Libc did not check the return value from kernel neither. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
