ALSA: hda - Fix possible races in HDMI driver - lockup on shutdown when radeon.audio=1 after using audacity
I have had reproducible lock-ups on shut-down (at the shutting down ALSA stage) of my AMD64 machine (Asus M3A78Pro motherboard, BIOS 1701 01/27/2011, CPU AMD Athlon(tm) II X4 640 Processor) running the 64 bit Linux kernel more recent than 3.12 when *both* radeon.audio=1 was set and I had been running audacity 2.0.5. (iommu=noaperture is also set). The problem was reproducible with the stock Debian kernel linux-image-3.13-rc6-amd64 version 3.13~rc6-1~exp1. The machine is using an ATI/AMD 3850HD video card with a DVI cable to a DVI input on my monitor, and the default audio device is the motherboard's on-board audio device: 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV670 [Radeon HD 3690/3850] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV670/680 HDMI Audio [Radeon HD 3690/3800 Series] $ git bisect bad cbbaa603a03cc46681e24d6b2804b62fde95a2af is the first bad commit commit cbbaa603a03cc46681e24d6b2804b62fde95a2af Author: Takashi Iwai Date: Thu Oct 17 18:03:24 2013 +0200 ALSA: hda - Fix possible races in HDMI driver Some per_pin fields and ELD contents might be changed dynamically in multiple ways where the concurrent accesses are still opened in the current code. This patch fixes such possible races by using eld->lock in appropriate places. Reported-by: Anssi Hannula Signed-off-by: Takashi Iwai :04 04 0c29281f82a3ebd9a704d481114f9cfcefea07c8 d71fd101125cd29a628cb5e66c7ee4f56e28329b M sound When running audacity from the command line there was the following output: ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611 Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611 Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4611 I am happy to supply further information or run further tests to help in isolating the problem and verifying a solution. Arthur. -- 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/
EFI stub: Booting Linux using EFI stub, Kernel panic, unflatten_device_tree, Arndale
Hello all, I try to boot with EFI stub on an Arndale, both with a provided dtb and with an appended dtb. With an appended dtb, I get "EFI stub: ERROR: Device tree header not valid." With a provided dtb, I get the below kernel panic. The reason I try to boot with the Shell is that if I just let the board boot (Boot Manager), I don't see any devices plugged in on usb or sata. It does say: [0.00] efi: Getting parameters from FDT: [0.00] efi: Can't find System Table in device tree! Which turns up empty in google. Kernel is patched with the patch series "[PATCH V6 0/8] Add ARM EFI stub" from Roy Franz. dtb is copied from arch/arm/boot/dts/exynos5250-arndale.dtb Do you have any tip as to what I can try to get the Arndale to boot? Sander # egrep 'EFI|DTB' .config CONFIG_EFI_PARTITION=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y # CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set # EFI (Extensible Firmware Interface) Support CONFIG_EFI_VARS=y CONFIG_UEFI_PARAMS_FROM_FDT=y CONFIG_EFIVAR_FS=y FS0:\> ver UEFI Interactive Shell v2.0 Copyright 2009-2013 Intel(r) Corporation. All rights reserved. UEFI v2.40 (ARM Platform EFI Jan 18 2014 21:50:23, 0x) FS0:\> zImage earlyprintk EFI stub: Booting Linux using EFI stub. EFI stub: ERROR: Device tree header not valid. FS0:\> zImage dtb=board.dtb earlyprintk EFI stub: Booting Linux using EFI stub. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.13.0-rc7-00368-g4530249-dirty (root@x301) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1 SMP PREEMPT Sun Jan 19 06:59:18 CET 2014 [0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Insignal Arndale evaluation board based on EXYNOS5250 [0.00] bootconsole [earlycon0] enabled [0.00] efi: Getting parameters from FDT: [0.00] UEFI v2.40 by ARM Platform EFI Jan 18 2014 21:50:23 [0.00] efi: [0.00] Memory policy: Data cache writealloc [0.00] CPU EXYNOS5250 (id 0x43520010) [0.00] Unable to handle kernel paging request at virtual address 07ff6000 [0.00] pgd = c0004000 [0.00] [07ff6000] *pgd= [0.00] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-rc7-00368-g4530249-dirty #1 [0.00] task: c0d86d68 ti: c0d7c000 task.ti: c0d7c000 [0.00] PC is at __unflatten_device_tree+0x1c/0x15c [0.00] LR is at unflatten_device_tree+0x28/0x34 [0.00] pc : []lr : []psr: 21d3 [0.00] sp : c0d7df50 ip : fp : [0.00] r10: c1e11140 r9 : 410fc0f4 r8 : c0d87bec [0.00] r7 : c057e7c8 r6 : c0d8c7b8 r5 : c0de4b74 r4 : 07ff6000 [0.00] r3 : feed r2 : c057e7c8 r1 : c0df6f48 r0 : 07ff6000 [0.00] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 4000406a DAC: 0015 [0.00] Process swapper (pid: 0, stack limit = 0xc0d7c240) [0.00] Stack: (0xc0d7df50 to 0xc0d7e000) [0.00] df40: 8fc0 c0d88b00 c0df6f48 c041660c [0.00] df60: c057e7c8 c0de4b74 c0d8c7b8 c0d87bec c0d87bec c0597d9c c059c9e0 c057dde8 [0.00] df80: 10c5387d 410fc0f4 c0411f14 c04da398 c0d7dfb4 [0.00] dfa0: c0d7dfc0 0001 c0d843c0 c0db9a80 7fff c057a860 [0.00] dfc0: bd94352e c05a0238 10c5387d [0.00] dfe0: c0d843ec c05a0234 c0d87d04 4000406a 40008074 [0.00] [] (__unflatten_device_tree+0x1c/0x15c) from [] (unflatten_device_tree+0x28/0x34) [0.00] [] (unflatten_device_tree+0x28/0x34) from [] (setup_arch+0x6a0/0x890) [0.00] [] (setup_arch+0x6a0/0x890) from [] (start_kernel+0xc8/0x3fc) [0.00] [] (start_kernel+0xc8/0x3fc) from [<40008074>] (0x40008074) [0.00] Code: e1a07002 e58d1008 0a3a e30f3eed (e5941000) [0.00] ---[ end trace 15c15b4afa9eff8e ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! -- 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] clk: export __clk_get_hw for re-use in others
Following build comes while modprobe process:
> ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
Export the symbol to fix it and for other part's usecase.
Signed-off-by: SeongJae Park
---
drivers/clk/clk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2b38dc9..3883fba 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk->hw;
}
+EXPORT_SYMBOL_GPL(__clk_get_hw);
u8 __clk_get_num_parents(struct clk *clk)
{
--
1.8.3.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: Please confirm your message
On Tue, 2014-01-14 at 17:04 +0100, Gmane Remailer wrote: > This message was created automatically by mail delivery software (TMDA). > > Your message attached below is being held because the address > has not been verified. > > To release your message for delivery, please send an empty message > to the following address, or use your mailer's "Reply" feature. > > > public-linux-kernel-u79uwxl29ty76z2rm5mhxa-confirm-1389715484.4811.fc3...@plane.gmane.org > > This confirmation verifies that your message is legitimate and not > junk-mail. You should only have to confirm your address once. > > If you do not respond to this confirmation request within 14 days, > your message will not be delivered. -- 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] Adding hyperv.h to uapi headers
> -Original Message-
> From: gurlige...@gmail.com [mailto:gurlige...@gmail.com] On Behalf Of Bjarke
> Istrup Pedersen
> Sent: Saturday, January 18, 2014 4:23 PM
> To: Linux Kernel Mailing List
> Cc: Haiyang Zhang; KY Srinivasan; Bjarke Istrup Pedersen
> Subject: Re: [PATCH v2] Adding hyperv.h to uapi headers
>
> Could any of you Hyper-V developers take a look at this, and see if
> this split makes sense to you?
Have you compiled the hyper-v drivers with your change. I briefly looked at your
latest patch but I did not see an include of the user level hyper-V driver in
the kernel
version of the header; or did I miss it. Please compile the drivers and the
tools/hv/
user level daemons to test your patch.
K. Y
>
> Thanks :)
>
> /Bjarke
>
> 2014/1/19 Bjarke Istrup Pedersen :
> > This patch adds the hyperv.h header to the uapi folder, and adds it to the
> > Kbuild
> file.
> > Doing this enables compiling userspace Hyper-V tools using the installed
> headers.
> >
> > Version 2: Split UAPI parts into new header, instead of duplicating.
> >
> > Signed-off-by: Bjarke Istrup Pedersen
> > ---
> > include/linux/hyperv.h | 321 +
> > include/uapi/linux/Kbuild | 1 +
> > include/uapi/linux/hyperv.h | 344
>
> > 3 files changed, 347 insertions(+), 319 deletions(-)
> > create mode 100644 include/uapi/linux/hyperv.h
> >
> > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> > index 15da677..167ef47 100644
> > --- a/include/linux/hyperv.h
> > +++ b/include/linux/hyperv.h
> > @@ -25,325 +25,9 @@
> > #ifndef _HYPERV_H
> > #define _HYPERV_H
> >
> > -#include
> > -
> > -/*
> > - * Framework version for util services.
> > - */
> > -#define UTIL_FW_MINOR 0
> > -
> > -#define UTIL_WS2K8_FW_MAJOR 1
> > -#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16 |
> UTIL_FW_MINOR)
> > -
> > -#define UTIL_FW_MAJOR 3
> > -#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 | UTIL_FW_MINOR)
> > -
> > -
> > -/*
> > - * Implementation of host controlled snapshot of the guest.
> > - */
> > -
> > -#define VSS_OP_REGISTER 128
> > -
> > -enum hv_vss_op {
> > - VSS_OP_CREATE = 0,
> > - VSS_OP_DELETE,
> > - VSS_OP_HOT_BACKUP,
> > - VSS_OP_GET_DM_INFO,
> > - VSS_OP_BU_COMPLETE,
> > - /*
> > -* Following operations are only supported with IC version >= 5.0
> > -*/
> > - VSS_OP_FREEZE, /* Freeze the file systems in the VM */
> > - VSS_OP_THAW, /* Unfreeze the file systems */
> > - VSS_OP_AUTO_RECOVER,
> > - VSS_OP_COUNT /* Number of operations, must be last */
> > -};
> > -
> > -
> > -/*
> > - * Header for all VSS messages.
> > - */
> > -struct hv_vss_hdr {
> > - __u8 operation;
> > - __u8 reserved[7];
> > -} __attribute__((packed));
> > -
> > -
> > -/*
> > - * Flag values for the hv_vss_check_feature. Linux supports only
> > - * one value.
> > - */
> > -#define VSS_HBU_NO_AUTO_RECOVERY 0x0005
> > -
> > -struct hv_vss_check_feature {
> > - __u32 flags;
> > -} __attribute__((packed));
> > -
> > -struct hv_vss_check_dm_info {
> > - __u32 flags;
> > -} __attribute__((packed));
> > -
> > -struct hv_vss_msg {
> > - union {
> > - struct hv_vss_hdr vss_hdr;
> > - int error;
> > - };
> > - union {
> > - struct hv_vss_check_feature vss_cf;
> > - struct hv_vss_check_dm_info dm_info;
> > - };
> > -} __attribute__((packed));
> > -
> > -/*
> > - * An implementation of HyperV key value pair (KVP) functionality for
> > Linux.
> > - *
> > - *
> > - * Copyright (C) 2010, Novell, Inc.
> > - * Author : K. Y. Srinivasan
> > - *
> > - */
> > -
> > -/*
> > - * Maximum value size - used for both key names and value data, and
> > includes
> > - * any applicable NULL terminators.
> > - *
> > - * Note: This limit is somewhat arbitrary, but falls easily within what is
> > - * supported for all native guests (back to Win 2000) and what is
> > reasonable
> > - * for the IC KVP exchange functionality. Note that Windows Me/98/95 are
> > - * limited to 255 character key names.
> > - *
> > - * MSDN recommends not storing data values larger than 2048 bytes in the
> > - * registry.
> > - *
> > - * Note: This value is used in defining the KVP exchange message - this
> > value
> > - * cannot be modified without affecting the message size and compatibility.
> > - */
> > -
> > -/*
> > - * bytes, including any null terminators
> > - */
> > -#define HV_KVP_EXCHANGE_MAX_VALUE_SIZE (2048)
> > -
> > -
> > -/*
> > - * Maximum key size - the registry limit for the length of an entry name
> > - * is 256 characters, including the null terminator
> > - */
> > -
> > -#define HV_KVP_EXCHANGE_MAX_KEY_SIZE(512)
> > +#include
> >
> > -/*
> > - * In Linux, we implement the KVP functionality in two components:
> > - * 1) The kernel component which is
RE: [PATCH] Adding hyperv.h to uapi headers
> -Original Message-
> From: Bjarke Istrup Pedersen [mailto:gurlige...@gmail.com] On Behalf Of Bjarke
> Istrup Pedersen
> Sent: Saturday, January 18, 2014 12:48 PM
> To: linux-kernel@vger.kernel.org
> Cc: Haiyang Zhang; Hank Janssen; KY Srinivasan; Bjarke Istrup Pedersen
> Subject: [PATCH] Adding hyperv.h to uapi headers
>
> This patch adds the hyperv.h header to the uapi folder, and adds it to the
> Kbuild
> file.
> Doing this enables compiling userspace Hyper-V tools using the installed
> headers.
>
Not all of the contents hyperv.h is needed for users-space programs.
I would not ack this patch.
K. Y
> Signed-off-by: Bjarke Istrup Pedersen
> ---
> include/uapi/linux/Kbuild |1 +
> include/uapi/linux/hyperv.h | 1469
> +++
> 2 files changed, 1470 insertions(+)
> create mode 100644 include/uapi/linux/hyperv.h
>
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index 33d2b8f..6389736 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -139,6 +139,7 @@ header-y += hid.h
> header-y += hiddev.h
> header-y += hidraw.h
> header-y += hpet.h
> +header-y += hyperv.h
> header-y += hysdn_if.h
> header-y += i2c-dev.h
> header-y += i2c.h
> diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h
> new file mode 100644
> index 000..15da677
> --- /dev/null
> +++ b/include/uapi/linux/hyperv.h
> @@ -0,0 +1,1469 @@
> +/*
> + *
> + * Copyright (c) 2011, Microsoft Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; if not, write to the Free Software Foundation, Inc., 59
> Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * Authors:
> + * Haiyang Zhang
> + * Hank Janssen
> + * K. Y. Srinivasan
> + *
> + */
> +
> +#ifndef _HYPERV_H
> +#define _HYPERV_H
> +
> +#include
> +
> +/*
> + * Framework version for util services.
> + */
> +#define UTIL_FW_MINOR 0
> +
> +#define UTIL_WS2K8_FW_MAJOR 1
> +#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16 |
> UTIL_FW_MINOR)
> +
> +#define UTIL_FW_MAJOR 3
> +#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 | UTIL_FW_MINOR)
> +
> +
> +/*
> + * Implementation of host controlled snapshot of the guest.
> + */
> +
> +#define VSS_OP_REGISTER 128
> +
> +enum hv_vss_op {
> + VSS_OP_CREATE = 0,
> + VSS_OP_DELETE,
> + VSS_OP_HOT_BACKUP,
> + VSS_OP_GET_DM_INFO,
> + VSS_OP_BU_COMPLETE,
> + /*
> + * Following operations are only supported with IC version >= 5.0
> + */
> + VSS_OP_FREEZE, /* Freeze the file systems in the VM */
> + VSS_OP_THAW, /* Unfreeze the file systems */
> + VSS_OP_AUTO_RECOVER,
> + VSS_OP_COUNT /* Number of operations, must be last */
> +};
> +
> +
> +/*
> + * Header for all VSS messages.
> + */
> +struct hv_vss_hdr {
> + __u8 operation;
> + __u8 reserved[7];
> +} __attribute__((packed));
> +
> +
> +/*
> + * Flag values for the hv_vss_check_feature. Linux supports only
> + * one value.
> + */
> +#define VSS_HBU_NO_AUTO_RECOVERY 0x0005
> +
> +struct hv_vss_check_feature {
> + __u32 flags;
> +} __attribute__((packed));
> +
> +struct hv_vss_check_dm_info {
> + __u32 flags;
> +} __attribute__((packed));
> +
> +struct hv_vss_msg {
> + union {
> + struct hv_vss_hdr vss_hdr;
> + int error;
> + };
> + union {
> + struct hv_vss_check_feature vss_cf;
> + struct hv_vss_check_dm_info dm_info;
> + };
> +} __attribute__((packed));
> +
> +/*
> + * An implementation of HyperV key value pair (KVP) functionality for Linux.
> + *
> + *
> + * Copyright (C) 2010, Novell, Inc.
> + * Author : K. Y. Srinivasan
> + *
> + */
> +
> +/*
> + * Maximum value size - used for both key names and value data, and includes
> + * any applicable NULL terminators.
> + *
> + * Note: This limit is somewhat arbitrary, but falls easily within what is
> + * supported for all native guests (back to Win 2000) and what is reasonable
> + * for the IC KVP exchange functionality. Note that Windows Me/98/95 are
> + * limited to 255 character key names.
> + *
> + * MSDN recommends not storing data values larger than 2048 bytes in the
> + * registry.
> + *
> + * Note: This value is used in defining the KVP exchange message - this
> value
> + * cannot be modified without affecting the message size and compatibility.
> + */
> +
> +/*
> + * bytes, including any null
[PATCH] exec: remove redundant check in search_binary_handler()
retval >= 0 is implied by retval != -ENOEXEC
Signed-off-by: Stefan Kristiansson
---
fs/exec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 7ea097f..aafafea 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1390,8 +1390,8 @@ int search_binary_handler(struct linux_binprm *bprm)
bprm->recursion_depth++;
retval = fmt->load_binary(bprm);
bprm->recursion_depth--;
- if (retval >= 0 || retval != -ENOEXEC ||
- bprm->mm == NULL || bprm->file == NULL) {
+ if (retval != -ENOEXEC || bprm->mm == NULL ||
+ bprm->file == NULL) {
put_binfmt(fmt);
return retval;
}
--
1.8.3.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] turbostat, servers do not support uncore power register
On Thu, Dec 19, 2013 at 7:27 PM, Prarit Bhargava wrote: > From the Intel Software Developer's Manual section 14.7.4, > > "For server platforms, PP1 domain is not supported, but its PP0 domain > supports the MSR_PP0_PERF_STATUS interface." > > When I run 'turbostat ls' I see the following error: > > /dev/cpu/0/msr offset 0x641 read failed Let me know if you see this when running turbostat v3.6 or later. you can find that version in the linux-next tree. thanks, Len Brown, Intel Open Source Technology Center -- 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 turbostat, replace numa based core ID with physical ID
NAK On Mon, Jan 6, 2014 at 8:04 AM, Prarit Bhargava wrote: > Len, here are some test results. > > On a 2-socket AMD 6276 system with the existing turbostat I see > > pk cor CPU GHz TSC > 0.74 1.15 > 0 0 8 1.48 2.30 > 0 1 9 1.48 2.30 > 0 2 10 1.53 2.30 > 0 3 11 1.46 2.30 > 0 4 12 1.49 2.30 > 0 5 13 1.47 2.30 > 0 6 14 1.48 2.30 > 0 7 15 1.54 2.30 > 1 0 24 1.49 2.30 > 1 1 25 1.48 2.30 > 1 2 26 1.48 2.30 > 1 3 27 1.51 2.30 > 1 4 28 1.52 2.30 > 1 5 29 1.43 2.30 > 1 6 30 1.51 2.30 > 1 7 31 1.49 2.30 > > As you can see only 8 of each 16 cores are reported. The issue is that the > core_id sysfs file is not physical-based; it is numa-based and it may differ > from that of the physical enumeration, especially in the cases where sockets > are split by numa nodes. It looks like we really want the physical core_id > and not the numa core_id. After the patch, > > pk cor CPU GHz TSC >1.47 2.30 > 0 0 0 1.46 2.30 > 0 1 1 1.44 2.30 > 0 2 2 1.51 2.30 > 0 3 3 1.49 2.30 > 0 4 4 1.51 2.30 > 0 5 5 1.51 2.30 > 0 6 6 1.49 2.30 > 0 7 7 1.49 2.30 > 0 8 8 1.47 2.30 > 0 9 9 1.48 2.30 > 0 10 10 1.64 2.30 > 0 11 11 1.54 2.30 > 0 12 12 1.51 2.30 > 0 13 13 1.46 2.30 > 0 14 14 1.49 2.30 > 0 15 15 1.46 2.30 > 1 0 16 1.49 2.30 > 1 1 17 1.44 2.30 > 1 2 18 1.51 2.30 > 1 3 19 1.44 2.30 > 1 4 20 1.50 2.30 > 1 5 21 1.44 2.30 > 1 6 22 1.50 2.30 > 1 7 23 1.44 2.30 > 1 8 24 1.48 2.30 > 1 9 25 1.46 2.30 > 1 10 26 1.47 2.30 > 1 11 27 1.49 2.30 > 1 12 28 1.52 2.30 > 1 13 29 1.43 2.30 > 1 14 30 1.51 2.30 > 1 15 31 1.45 2.30 > > As a sanity check I also ran on a dual-socket E5-26XX v2 system: > > pk cor CPU%c0 GHz TSC SMI%c1%c3%c6%c7 CTMP PTMP %pc2 > %pc3 %pc6 %pc7 Pkg_W Cor_W RAM_W PKG_% RAM_% > 0.04 1.30 2.69 0 0.12 0.00 99.84 0.00 32 32 12.28 > 0.00 86.59 0.00 11.20 2.74 6.48 0.00 0.00 > 0 0 0 0.23 1.20 2.69 0 0.43 0.00 99.34 0.00 26 27 12.39 > 0.00 86.61 0.00 5.76 1.53 1.85 0.00 0.00 > 0 0 20 0.05 1.21 2.69 0 0.61 > 0 1 1 0.02 1.23 2.69 0 0.08 0.00 99.90 0.00 26 > 0 1 21 0.02 1.26 2.69 0 0.08 > 0 2 2 0.02 1.29 2.69 0 0.06 0.00 99.92 0.00 25 > 0 2 22 0.02 1.35 2.69 0 0.06 > 0 3 3 0.02 1.28 2.69 0 0.06 0.00 99.92 0.00 25 > 0 3 23 0.02 1.35 2.69 0 0.06 > 0 4 4 0.03 1.25 2.69 0 0.06 0.00 99.90 0.00 32 > 0 4 24 0.02 1.33 2.69 0 0.08 > 0 9 5 0.02 1.35 2.69 0 0.05 0.00 99.93 0.00 28 > 0 9 25 0.02 1.34 2.69 0 0.05 > 0 10 6 0.02 1.25 2.69 0 0.05 0.00 99.93 0.00 21 > 0 10 26 0.02 1.34 2.69 0 0.05 > 0 11 7 0.02 1.29 2.69 0 0.06 0.00 99.92 0.00 32 > 0 11 27 0.02 1.35 2.69 0 0.06 > 0 12 8 0.02 1.27 2.69 0 0.06 0.00 99.92 0.00 31 > 0 12 28 0.02 1.33 2.69 0 0.06 > 0 13 9 0.02 1.25 2.69 0 0.05 0.00 99.93 0.00 20 > 0 13 29 0.02 1.30 2.69 0 0.06 > 1 0 10 0.04 1.23 2.69 0 0.10 0.00 99.86 0.00 29 32 12.16 > 0.00 86.59 0.00 5.45 1.22 4.63 0.00 0.00 > 1 0 30 0.03 1.20 2.69 0 0.11 > 1 1 11 0.04 1.20 2.69 0 0.10 0.00 99.86 0.00 30 > 1 1 31 0.03 1.20 2.69 0 0.11 > 1 2 12 0.03 1.20 2.69 0 0.08 0.00 99.89 0.00 29 > 1 2 32 0.02 1.20 2.69 0 0.09 > 1 3 13 0.21 1.20 2.69 0 0.11 0.00 99.68 0.00 29 > 1 3 33 0.03 1.20 2.69 0 0.30 > 1 4 14 0.04 1.20 2.69 0 0.08 0.00 99.88 0.00 31 > 1 4 34 0.02 1.20 2.69 0 0.10 > 1 9 15 0.03 1.20 2.69 0 0.08 0.00 99.88 0.00 26 > 1 9 35 0.02 1.20 2.69 0 0.10 > 1 10 16 0.03 1.20 2.69 0 0.08 0.00 99.89 0.00 28 > 1 10 36 0.02 1.20 2.69 0 0.09 > 1 11 17 0.03 1.20 2.69 0 0.08 0.00 99.89 0.00 26 > 1 11 37 0.02 1.20 2.69 0 0.09 > 1 12 18 0.33 1.44 2.69 0 0.09 0.00 99.58 0.00 25 > 1 12 38 0.02 1.20 2.69 0 0.40 > 1 13 19 0.11 1.74 2.69 0 0.10 0.00 99.79 0.00 31 > 1 13 39 0.03 1.20 2.69 0 0.17 > > And after the patch, > > pk cor CPU%c0 GHz TSC SMI%c1%c3%c6%c7 CTMP PTMP %pc2 > %pc3 %pc6 %pc7 Pkg_W Cor_W RAM_W PKG_% RAM_% > 0.04 1.22 2.69 0 50.05 0.00 99.83 0.00 33 32 12.29 > 0.00 86.75 0.00 11.33 2.73 6.35 0.00 0.00 > 0 0 0 0.14 1.21 2.69 0 0.34 0.00 99.53 0.00 26 27 12.43 > 0.00 86.77 0.00 5.83 1.53 1.92 0.00 0.00 > 0 1 1 0.02 1.24 2.69 0 0.06 0.00 99.92 0.00 26 > 0 2 2 0.02 1.29 2.69 0 0.09 0.00 99.90 0.00 26 > 0 3 3 0.02 1.31 2.69 0 0.09 0.00 99.89 0.00 24 > 0 4 4
[PATCH-v2 10/17] target: Add protection SGLs to target_submit_cmd_map_sgls
From: Nicholas Bellinger
This patch adds support to target_submit_cmd_map_sgls() for
accepting 'sgl_prot' + 'sgl_prot_count' parameters for
DIF protection information.
Note the passed parameters are stored at se_cmd->t_prot_sg
and se_cmd->t_prot_nents respectively.
Also, update tcm_loop and vhost-scsi fabrics usage of
target_submit_cmd_map_sgls() to take into account the
new parameters.
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/loopback/tcm_loop.c |2 +-
drivers/target/target_core_transport.c | 16 ++--
drivers/vhost/scsi.c |2 +-
include/target/target_core_fabric.h|3 ++-
4 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/target/loopback/tcm_loop.c
b/drivers/target/loopback/tcm_loop.c
index 763ee45..112b795 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -217,7 +217,7 @@ static void tcm_loop_submission_work(struct work_struct
*work)
scsi_bufflen(sc), tcm_loop_sam_attr(sc),
sc->sc_data_direction, 0,
scsi_sglist(sc), scsi_sg_count(sc),
- sgl_bidi, sgl_bidi_count);
+ sgl_bidi, sgl_bidi_count, NULL, 0);
if (rc < 0) {
set_host_byte(sc, DID_NO_CONNECT);
goto out_done;
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index fa4fc04..aebe0bb 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1310,6 +1310,8 @@ transport_generic_map_mem_to_cmd(struct se_cmd *cmd,
struct scatterlist *sgl,
* @sgl_count: scatterlist count for unidirectional mapping
* @sgl_bidi: struct scatterlist memory for bidirectional READ mapping
* @sgl_bidi_count: scatterlist count for bidirectional READ mapping
+ * @sgl_prot: struct scatterlist memory protection information
+ * @sgl_prot_count: scatterlist count for protection information
*
* Returns non zero to signal active I/O shutdown failure. All other
* setup exceptions will be returned as a SCSI CHECK_CONDITION response,
@@ -1322,7 +1324,8 @@ int target_submit_cmd_map_sgls(struct se_cmd *se_cmd,
struct se_session *se_sess
unsigned char *cdb, unsigned char *sense, u32 unpacked_lun,
u32 data_length, int task_attr, int data_dir, int flags,
struct scatterlist *sgl, u32 sgl_count,
- struct scatterlist *sgl_bidi, u32 sgl_bidi_count)
+ struct scatterlist *sgl_bidi, u32 sgl_bidi_count,
+ struct scatterlist *sgl_prot, u32 sgl_prot_count)
{
struct se_portal_group *se_tpg;
sense_reason_t rc;
@@ -1364,6 +1367,14 @@ int target_submit_cmd_map_sgls(struct se_cmd *se_cmd,
struct se_session *se_sess
target_put_sess_cmd(se_sess, se_cmd);
return 0;
}
+ /*
+* Save pointers for SGLs containing protection information,
+* if present.
+*/
+ if (sgl_prot_count) {
+ se_cmd->t_prot_sg = sgl_prot;
+ se_cmd->t_prot_nents = sgl_prot_count;
+ }
rc = target_setup_cmd_from_cdb(se_cmd, cdb);
if (rc != 0) {
@@ -1406,6 +1417,7 @@ int target_submit_cmd_map_sgls(struct se_cmd *se_cmd,
struct se_session *se_sess
return 0;
}
}
+
/*
* Check if we need to delay processing because of ALUA
* Active/NonOptimized primary access state..
@@ -1445,7 +1457,7 @@ int target_submit_cmd(struct se_cmd *se_cmd, struct
se_session *se_sess,
{
return target_submit_cmd_map_sgls(se_cmd, se_sess, cdb, sense,
unpacked_lun, data_length, task_attr, data_dir,
- flags, NULL, 0, NULL, 0);
+ flags, NULL, 0, NULL, 0, NULL, 0);
}
EXPORT_SYMBOL(target_submit_cmd);
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index f175629..84488a8 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -889,7 +889,7 @@ static void tcm_vhost_submission_work(struct work_struct
*work)
cmd->tvc_lun, cmd->tvc_exp_data_len,
cmd->tvc_task_attr, cmd->tvc_data_direction,
TARGET_SCF_ACK_KREF, sg_ptr, cmd->tvc_sgl_count,
- sg_bidi_ptr, sg_no_bidi);
+ sg_bidi_ptr, sg_no_bidi, NULL, 0);
if (rc < 0) {
transport_send_check_condition_and_sense(se_cmd,
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, 0);
diff --git a/include/target/target_core_fabric.h
b/include/target/target_core_fabric.h
index 4cf4fda..0218d68 100644
--- a/include/target/target_core_fabric.h
+++ b/include/target/target_core_fabric.h
@@ -105,7 +105,8 @@
[PATCH-v2 04/17] target/sbc: Add DIF TYPE1+TYPE3 read/write verify emulation
From: Nicholas Bellinger
This patch adds support for DIF read/write verify emulation
for TARGET_DIF_TYPE1_PROT + TARGET_DIF_TYPE3_PROT operation.
This includes sbc_dif_verify_write() + sbc_dif_verify_read()
calls accessable by backend drivers to perform DIF verify
for SGL based data and protection information.
Also included is sbc_dif_copy_prot() logic to copy protection
information to/from backend provided protection SGLs.
Based on scsi_debug.c DIF TYPE1+TYPE3 emulation.
v2 changes:
- Select CRC_T10DIF for TARGET_CORE in Kconfig (Fengguang)
- Drop IP checksum logic from sbc_dif_v1_verify (MKP)
- Fix offset on app_tag = 0x in sbc_dif_verify_read()
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/Kconfig |1 +
drivers/target/target_core_sbc.c | 178 ++
include/target/target_core_backend.h |4 +
3 files changed, 183 insertions(+)
diff --git a/drivers/target/Kconfig b/drivers/target/Kconfig
index 1830368..50aad2e 100644
--- a/drivers/target/Kconfig
+++ b/drivers/target/Kconfig
@@ -3,6 +3,7 @@ menuconfig TARGET_CORE
tristate "Generic Target Core Mod (TCM) and ConfigFS Infrastructure"
depends on SCSI && BLOCK
select CONFIGFS_FS
+ select CRC_T10DIF
default n
help
Say Y or M here to enable the TCM Storage Engine and ConfigFS enabled
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 91a92f3..26e8bfb 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1024,3 +1025,180 @@ err:
return ret;
}
EXPORT_SYMBOL(sbc_execute_unmap);
+
+static sense_reason_t
+sbc_dif_v1_verify(struct se_device *dev, struct se_dif_v1_tuple *sdt,
+ const void *p, sector_t sector, unsigned int ei_lba)
+{
+ int block_size = dev->dev_attrib.block_size;
+ __be16 csum;
+
+ csum = cpu_to_be16(crc_t10dif(p, block_size));
+
+ if (sdt->guard_tag != csum) {
+ pr_err("DIFv1 checksum failed on sector %llu guard tag 0x%04x"
+ " csum 0x%04x\n", (unsigned long long)sector,
+ be16_to_cpu(sdt->guard_tag), be16_to_cpu(csum));
+ return TCM_LOGICAL_BLOCK_GUARD_CHECK_FAILED;
+ }
+
+ if (dev->dev_attrib.pi_prot_type == TARGET_DIF_TYPE1_PROT &&
+ be32_to_cpu(sdt->ref_tag) != (sector & 0x)) {
+ pr_err("DIFv1 Type 1 reference failed on sector: %llu tag:
0x%08x"
+ " sector MSB: 0x%08x\n", (unsigned long long)sector,
+ be32_to_cpu(sdt->ref_tag), (u32)(sector & 0x));
+ return TCM_LOGICAL_BLOCK_REF_TAG_CHECK_FAILED;
+ }
+
+ if (dev->dev_attrib.pi_prot_type == TARGET_DIF_TYPE2_PROT &&
+ be32_to_cpu(sdt->ref_tag) != ei_lba) {
+ pr_err("DIFv1 Type 2 reference failed on sector: %llu tag:
0x%08x"
+ " ei_lba: 0x%08x\n", (unsigned long long)sector,
+ be32_to_cpu(sdt->ref_tag), ei_lba);
+ return TCM_LOGICAL_BLOCK_REF_TAG_CHECK_FAILED;
+ }
+
+ return 0;
+}
+
+static void
+sbc_dif_copy_prot(struct se_cmd *cmd, unsigned int sectors, bool read,
+ struct scatterlist *sg, int sg_off)
+{
+ struct se_device *dev = cmd->se_dev;
+ struct scatterlist *psg;
+ void *paddr, *addr;
+ unsigned int i, len, left;
+
+ left = sectors * dev->prot_length;
+
+ for_each_sg(cmd->t_prot_sg, psg, cmd->t_prot_nents, i) {
+
+ len = min(psg->length, left);
+ paddr = kmap_atomic(sg_page(psg)) + psg->offset;
+ addr = kmap_atomic(sg_page(sg)) + sg_off;
+
+ if (read)
+ memcpy(paddr, addr, len);
+ else
+ memcpy(addr, paddr, len);
+
+ left -= len;
+ kunmap_atomic(paddr);
+ kunmap_atomic(addr);
+ }
+}
+
+sense_reason_t
+sbc_dif_verify_write(struct se_cmd *cmd, sector_t start, unsigned int sectors,
+unsigned int ei_lba, struct scatterlist *sg, int sg_off)
+{
+ struct se_device *dev = cmd->se_dev;
+ struct se_dif_v1_tuple *sdt;
+ struct scatterlist *dsg, *psg = cmd->t_prot_sg;
+ sector_t sector = start;
+ void *daddr, *paddr;
+ int i, j, offset = 0;
+ sense_reason_t rc;
+
+ for_each_sg(cmd->t_data_sg, dsg, cmd->t_data_nents, i) {
+ daddr = kmap_atomic(sg_page(dsg)) + dsg->offset;
+ paddr = kmap_atomic(sg_page(psg)) + psg->offset;
+
+ for (j = 0; j < dsg->length; j += dev->dev_attrib.block_size) {
+
+ if (offset >= psg->length) {
+
[PATCH-v2 07/17] target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY_16
From: Nicholas Bellinger This patch updates sbc_emulate_readcapacity_16() to set P_TYPE and PROT_EN bits when DIF emulation is enabled by the backend device. Reviewed-by: Martin K. Petersen Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger --- drivers/target/target_core_sbc.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c index 26e8bfb..75364c7 100644 --- a/drivers/target/target_core_sbc.c +++ b/drivers/target/target_core_sbc.c @@ -106,6 +106,11 @@ sbc_emulate_readcapacity_16(struct se_cmd *cmd) buf[9] = (dev->dev_attrib.block_size >> 16) & 0xff; buf[10] = (dev->dev_attrib.block_size >> 8) & 0xff; buf[11] = dev->dev_attrib.block_size & 0xff; + /* +* Set P_TYPE and PROT_EN bits for DIF support +*/ + if (dev->dev_attrib.pi_prot_type) + buf[12] = (dev->dev_attrib.pi_prot_type - 1) << 1 | 0x1; if (dev->transport->get_lbppbe) buf[13] = dev->transport->get_lbppbe(dev) & 0x0f; -- 1.7.10.4 -- 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 08/17] target/spc: Expose ATO bit in control mode page
From: Nicholas Bellinger This patch updates spc_modesense_control() to set the Application Tag Owner (ATO) bit when when DIF emulation is enabled by the backend device. Reviewed-by: Martin K. Petersen Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger --- drivers/target/target_core_spc.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c index 73fdff5..43c5ca98 100644 --- a/drivers/target/target_core_spc.c +++ b/drivers/target/target_core_spc.c @@ -858,6 +858,19 @@ static int spc_modesense_control(struct se_device *dev, u8 pc, u8 *p) * status (see SAM-4). */ p[5] = (dev->dev_attrib.emulate_tas) ? 0x40 : 0x00; + /* +* From spc4r30, section 7.5.7 Control mode page +* +* Application Tag Owner (ATO) bit set to one. +* +* If the ATO bit is set to one the device server shall not modify the +* LOGICAL BLOCK APPLICATION TAG field and, depending on the protection +* type, shall not modify the contents of the LOGICAL BLOCK REFERENCE +* TAG field. +*/ + if (dev->dev_attrib.pi_prot_type) + p[5] |= 0x80; + p[8] = 0xff; p[9] = 0xff; p[11] = 30; -- 1.7.10.4 -- 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 02/17] target: Add DIF CHECK_CONDITION ASC/ASCQ exception cases
From: Nicholas Bellinger
This patch adds support for DIF related CHECK_CONDITION ASC/ASCQ
exception cases into transport_send_check_condition_and_sense().
This includes:
LOGICAL BLOCK GUARD CHECK FAILED
LOGICAL BLOCK APPLICATION TAG CHECK FAILED
LOGICAL BLOCK REFERENCE TAG CHECK FAILED
that used by DIF TYPE1 and TYPE3 failure cases.
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_transport.c | 30 ++
include/target/target_core_base.h |3 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 18c828d..fa4fc04 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2674,6 +2674,36 @@ transport_send_check_condition_and_sense(struct se_cmd
*cmd,
buffer[SPC_ASC_KEY_OFFSET] = 0x1d;
buffer[SPC_ASCQ_KEY_OFFSET] = 0x00;
break;
+ case TCM_LOGICAL_BLOCK_GUARD_CHECK_FAILED:
+ /* CURRENT ERROR */
+ buffer[0] = 0x70;
+ buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
+ /* ILLEGAL REQUEST */
+ buffer[SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST;
+ /* LOGICAL BLOCK GUARD CHECK FAILED */
+ buffer[SPC_ASC_KEY_OFFSET] = 0x10;
+ buffer[SPC_ASCQ_KEY_OFFSET] = 0x01;
+ break;
+ case TCM_LOGICAL_BLOCK_APP_TAG_CHECK_FAILED:
+ /* CURRENT ERROR */
+ buffer[0] = 0x70;
+ buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
+ /* ILLEGAL REQUEST */
+ buffer[SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST;
+ /* LOGICAL BLOCK APPLICATION TAG CHECK FAILED */
+ buffer[SPC_ASC_KEY_OFFSET] = 0x10;
+ buffer[SPC_ASCQ_KEY_OFFSET] = 0x02;
+ break;
+ case TCM_LOGICAL_BLOCK_REF_TAG_CHECK_FAILED:
+ /* CURRENT ERROR */
+ buffer[0] = 0x70;
+ buffer[SPC_ADD_SENSE_LEN_OFFSET] = 10;
+ /* ILLEGAL REQUEST */
+ buffer[SPC_SENSE_KEY_OFFSET] = ILLEGAL_REQUEST;
+ /* LOGICAL BLOCK REFERENCE TAG CHECK FAILED */
+ buffer[SPC_ASC_KEY_OFFSET] = 0x10;
+ buffer[SPC_ASCQ_KEY_OFFSET] = 0x03;
+ break;
case TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE:
default:
/* CURRENT ERROR */
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index d98048b..0336d70 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -205,6 +205,9 @@ enum tcm_sense_reason_table {
TCM_OUT_OF_RESOURCES= R(0x12),
TCM_PARAMETER_LIST_LENGTH_ERROR = R(0x13),
TCM_MISCOMPARE_VERIFY = R(0x14),
+ TCM_LOGICAL_BLOCK_GUARD_CHECK_FAILED= R(0x15),
+ TCM_LOGICAL_BLOCK_APP_TAG_CHECK_FAILED = R(0x16),
+ TCM_LOGICAL_BLOCK_REF_TAG_CHECK_FAILED = R(0x17),
#undef R
};
--
1.7.10.4
--
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 06/17] target/spc: Add protection related bits to INQUIRY EVPD=0x86
From: Nicholas Bellinger This patch updates spc_emulate_evpd_86() (extended INQUIRY) to report GRD_CHK (Guard Check) and REF_CHK (Reference Check) bits when DIF emulation is enabled by the backend device. Reviewed-by: Martin K. Petersen Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger --- drivers/target/target_core_spc.c |9 + 1 file changed, 9 insertions(+) diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c index 4178c2a..73fdff5 100644 --- a/drivers/target/target_core_spc.c +++ b/drivers/target/target_core_spc.c @@ -475,6 +475,15 @@ spc_emulate_evpd_86(struct se_cmd *cmd, unsigned char *buf) struct se_device *dev = cmd->se_dev; buf[3] = 0x3c; + /* +* Set GRD_CHK + REF_CHK for TYPE1 protection, or GRD_CHK +* only for TYPE3 protection. +*/ + if (dev->dev_attrib.pi_prot_type == TARGET_DIF_TYPE1_PROT) + buf[4] = 0x5; + else if (dev->dev_attrib.pi_prot_type == TARGET_DIF_TYPE3_PROT) + buf[4] = 0x4; + /* Set HEADSUP, ORDSUP, SIMPSUP */ buf[5] = 0x07; -- 1.7.10.4 -- 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: Help Needed
You can just go to http://www.kernel.org to get the Linux kernel source code. If you want to use a certain Linux distribution, search "Linux distributions" using your favorite Web search engine. Sent from my iPad > On Jan 18, 2014, at 2:16 PM, Randy Dunlap wrote: > >> On 01/18/2014 09:34 AM, Madhusudhan Rao Sripalle wrote: >> Hi, >> >> I am an expert of HP-UX (kernel and drivers), while being novice at >> linux. I am currently looking ways for quick ramp up so that I could >> contribute to linux community. >> >> Kindly provide pointers starting from where I could get the kernel >> sources. Appreciate help in advance. > > google for "linux kernel source" -- the top 2 URLs give you the kernel > source trees ... unless you want the source for some particular distro > like Red Hat, SuSE, Ubuntu, ArchLinux, etc., then you would need to go > to the web sites of those distros to find the sources. > > Also check http://kernelnewbies.org/ for some newbie info. > > -- > ~Randy > -- > 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/ -- 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 11/17] target/iblock: Add blk_integrity + BIP passthrough support
From: Nicholas Bellinger
This patch adds blk_integrity passthrough support for block_device
backends using IBLOCK.
This includes iblock_alloc_bip() + setup of bio_integrity_payload
information that attaches to the leading struct bio once bio_list
is populated during fast-path iblock_execute_rw() I/O dispatch.
It also updates setup in iblock_configure_device() to detect modes
of protection + se dev->dev_attrib.pi_prot_type accordingly, along
with creating required bio_set integrity mempools.
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/Kconfig |1 +
drivers/target/target_core_iblock.c | 91 ++-
2 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/drivers/target/Kconfig b/drivers/target/Kconfig
index 50aad2e..dc2d84a 100644
--- a/drivers/target/Kconfig
+++ b/drivers/target/Kconfig
@@ -14,6 +14,7 @@ if TARGET_CORE
config TCM_IBLOCK
tristate "TCM/IBLOCK Subsystem Plugin for Linux/BLOCK"
+ select BLK_DEV_INTEGRITY
help
Say Y here to enable the TCM/IBLOCK subsystem plugin for non-buffered
access to Linux/Block devices using BIO
diff --git a/drivers/target/target_core_iblock.c
b/drivers/target/target_core_iblock.c
index 15d9121..293d9b0 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -91,6 +91,7 @@ static int iblock_configure_device(struct se_device *dev)
struct iblock_dev *ib_dev = IBLOCK_DEV(dev);
struct request_queue *q;
struct block_device *bd = NULL;
+ struct blk_integrity *bi;
fmode_t mode;
int ret = -ENOMEM;
@@ -155,8 +156,40 @@ static int iblock_configure_device(struct se_device *dev)
if (blk_queue_nonrot(q))
dev->dev_attrib.is_nonrot = 1;
+ bi = bdev_get_integrity(bd);
+ if (bi) {
+ struct bio_set *bs = ib_dev->ibd_bio_set;
+
+ if (!strcmp(bi->name, "T10-DIF-TYPE3-IP") ||
+ !strcmp(bi->name, "T10-DIF-TYPE1-IP")) {
+ pr_err("IBLOCK export of blk_integrity: %s not"
+ " supported\n", bi->name);
+ ret = -ENOSYS;
+ goto out_blkdev_put;
+ }
+
+ if (!strcmp(bi->name, "T10-DIF-TYPE3-CRC")) {
+ dev->dev_attrib.pi_prot_type = TARGET_DIF_TYPE3_PROT;
+ } else if (!strcmp(bi->name, "T10-DIF-TYPE1-CRC")) {
+ dev->dev_attrib.pi_prot_type = TARGET_DIF_TYPE1_PROT;
+ }
+
+ if (dev->dev_attrib.pi_prot_type) {
+ if (bioset_integrity_create(bs, IBLOCK_BIO_POOL_SIZE) <
0) {
+ pr_err("Unable to allocate bioset for PI\n");
+ ret = -ENOMEM;
+ goto out_blkdev_put;
+ }
+ pr_debug("IBLOCK setup BIP bs->bio_integrity_pool:
%p\n",
+bs->bio_integrity_pool);
+ }
+ dev->dev_attrib.hw_pi_prot_type = dev->dev_attrib.pi_prot_type;
+ }
+
return 0;
+out_blkdev_put:
+ blkdev_put(ib_dev->ibd_bd, FMODE_WRITE|FMODE_READ|FMODE_EXCL);
out_free_bioset:
bioset_free(ib_dev->ibd_bio_set);
ib_dev->ibd_bio_set = NULL;
@@ -170,8 +203,10 @@ static void iblock_free_device(struct se_device *dev)
if (ib_dev->ibd_bd != NULL)
blkdev_put(ib_dev->ibd_bd, FMODE_WRITE|FMODE_READ|FMODE_EXCL);
- if (ib_dev->ibd_bio_set != NULL)
+ if (ib_dev->ibd_bio_set != NULL) {
+ bioset_integrity_free(ib_dev->ibd_bio_set);
bioset_free(ib_dev->ibd_bio_set);
+ }
kfree(ib_dev);
}
@@ -586,13 +621,58 @@ static ssize_t iblock_show_configfs_dev_params(struct
se_device *dev, char *b)
return bl;
}
+static int
+iblock_alloc_bip(struct se_cmd *cmd, struct bio *bio)
+{
+ struct se_device *dev = cmd->se_dev;
+ struct blk_integrity *bi;
+ struct bio_integrity_payload *bip;
+ struct iblock_dev *ib_dev = IBLOCK_DEV(dev);
+ struct scatterlist *sg;
+ int i, rc;
+
+ bi = bdev_get_integrity(ib_dev->ibd_bd);
+ if (!bi) {
+ pr_err("Unable to locate bio_integrity\n");
+ return -ENODEV;
+ }
+
+ bip = bio_integrity_alloc(bio, GFP_NOIO, cmd->t_prot_nents);
+ if (!bip) {
+ pr_err("Unable to allocate bio_integrity_payload\n");
+ return -ENOMEM;
+ }
+
+ bip->bip_size = (cmd->data_length / dev->dev_attrib.block_size) *
+dev->prot_length;
+ bip->bip_sector = bio->bi_sector;
+
+ pr_debug("IBLOCK BIP Size: %u Sector: %llu\n", bip->bip_size,
+(unsigned long long)bip->bip_sector);
+
+
[PATCH-v2 14/17] target/rd: Refactor rd_build_device_space + rd_release_device_space
From: Nicholas Bellinger
This patch refactors rd_build_device_space() + rd_release_device_space()
into rd_allocate_sgl_table() + rd_release_device_space() so that they
may be used seperatly for setup + release of protection information
scatterlists.
Also add explicit memset of pages within rd_allocate_sgl_table() based
upon passed 'init_payload' value.
v2 changes:
- Drop unused sg_table from rd_release_device_space (Wei)
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_rd.c | 113 +++
1 file changed, 68 insertions(+), 45 deletions(-)
diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index 4ffe5f2..e9fa879 100644
--- a/drivers/target/target_core_rd.c
+++ b/drivers/target/target_core_rd.c
@@ -78,23 +78,14 @@ static void rd_detach_hba(struct se_hba *hba)
hba->hba_ptr = NULL;
}
-/* rd_release_device_space():
- *
- *
- */
-static void rd_release_device_space(struct rd_dev *rd_dev)
+static u32 rd_release_sgl_table(struct rd_dev *rd_dev, struct rd_dev_sg_table
*sg_table,
+u32 sg_table_count)
{
- u32 i, j, page_count = 0, sg_per_table;
- struct rd_dev_sg_table *sg_table;
struct page *pg;
struct scatterlist *sg;
+ u32 i, j, page_count = 0, sg_per_table;
- if (!rd_dev->sg_table_array || !rd_dev->sg_table_count)
- return;
-
- sg_table = rd_dev->sg_table_array;
-
- for (i = 0; i < rd_dev->sg_table_count; i++) {
+ for (i = 0; i < sg_table_count; i++) {
sg = sg_table[i].sg_table;
sg_per_table = sg_table[i].rd_sg_count;
@@ -105,16 +96,28 @@ static void rd_release_device_space(struct rd_dev *rd_dev)
page_count++;
}
}
-
kfree(sg);
}
+ kfree(sg_table);
+ return page_count;
+}
+
+static void rd_release_device_space(struct rd_dev *rd_dev)
+{
+ u32 page_count;
+
+ if (!rd_dev->sg_table_array || !rd_dev->sg_table_count)
+ return;
+
+ page_count = rd_release_sgl_table(rd_dev, rd_dev->sg_table_array,
+ rd_dev->sg_table_count);
+
pr_debug("CORE_RD[%u] - Released device space for Ramdisk"
" Device ID: %u, pages %u in %u tables total bytes %lu\n",
rd_dev->rd_host->rd_host_id, rd_dev->rd_dev_id, page_count,
rd_dev->sg_table_count, (unsigned long)page_count * PAGE_SIZE);
- kfree(sg_table);
rd_dev->sg_table_array = NULL;
rd_dev->sg_table_count = 0;
}
@@ -124,38 +127,15 @@ static void rd_release_device_space(struct rd_dev *rd_dev)
*
*
*/
-static int rd_build_device_space(struct rd_dev *rd_dev)
+static int rd_allocate_sgl_table(struct rd_dev *rd_dev, struct rd_dev_sg_table
*sg_table,
+u32 total_sg_needed, unsigned char
init_payload)
{
- u32 i = 0, j, page_offset = 0, sg_per_table, sg_tables, total_sg_needed;
+ u32 i = 0, j, page_offset = 0, sg_per_table;
u32 max_sg_per_table = (RD_MAX_ALLOCATION_SIZE /
sizeof(struct scatterlist));
- struct rd_dev_sg_table *sg_table;
struct page *pg;
struct scatterlist *sg;
-
- if (rd_dev->rd_page_count <= 0) {
- pr_err("Illegal page count: %u for Ramdisk device\n",
- rd_dev->rd_page_count);
- return -EINVAL;
- }
-
- /* Don't need backing pages for NULLIO */
- if (rd_dev->rd_flags & RDF_NULLIO)
- return 0;
-
- total_sg_needed = rd_dev->rd_page_count;
-
- sg_tables = (total_sg_needed / max_sg_per_table) + 1;
-
- sg_table = kzalloc(sg_tables * sizeof(struct rd_dev_sg_table),
GFP_KERNEL);
- if (!sg_table) {
- pr_err("Unable to allocate memory for Ramdisk"
- " scatterlist tables\n");
- return -ENOMEM;
- }
-
- rd_dev->sg_table_array = sg_table;
- rd_dev->sg_table_count = sg_tables;
+ unsigned char *p;
while (total_sg_needed) {
sg_per_table = (total_sg_needed > max_sg_per_table) ?
@@ -186,16 +166,59 @@ static int rd_build_device_space(struct rd_dev *rd_dev)
}
sg_assign_page([j], pg);
sg[j].length = PAGE_SIZE;
+
+ p = kmap(pg);
+ memset(p, init_payload, PAGE_SIZE);
+ kunmap(pg);
}
page_offset += sg_per_table;
total_sg_needed -= sg_per_table;
}
+ return 0;
+}
+
+static int rd_build_device_space(struct rd_dev *rd_dev)
+{
+ struct rd_dev_sg_table *sg_table;
+ u32 sg_tables,
[PATCH-v2 15/17] target/rd: Add support for protection SGL setup + release
From: Nicholas Bellinger
This patch adds rd_build_prot_space() + rd_release_prot_space() logic
to setup + release protection information scatterlists.
It also adds rd_init_prot() + rd_free_prot() se_subsystem_api
callbacks used by target core code for setup + release of
protection information.
v2 changes:
- Drop unused sg_table from rd_release_prot_space (Wei)
- Drop rd_release_prot_space call from rd_free_device
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_rd.c | 74 +++
drivers/target/target_core_rd.h |4 +++
2 files changed, 78 insertions(+)
diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index e9fa879..660961d 100644
--- a/drivers/target/target_core_rd.c
+++ b/drivers/target/target_core_rd.c
@@ -223,6 +223,61 @@ static int rd_build_device_space(struct rd_dev *rd_dev)
return 0;
}
+static void rd_release_prot_space(struct rd_dev *rd_dev)
+{
+ u32 page_count;
+
+ if (!rd_dev->sg_prot_array || !rd_dev->sg_prot_count)
+ return;
+
+ page_count = rd_release_sgl_table(rd_dev, rd_dev->sg_prot_array,
+ rd_dev->sg_prot_count);
+
+ pr_debug("CORE_RD[%u] - Released protection space for Ramdisk"
+" Device ID: %u, pages %u in %u tables total bytes %lu\n",
+rd_dev->rd_host->rd_host_id, rd_dev->rd_dev_id, page_count,
+rd_dev->sg_table_count, (unsigned long)page_count * PAGE_SIZE);
+
+ rd_dev->sg_prot_array = NULL;
+ rd_dev->sg_prot_count = 0;
+}
+
+static int rd_build_prot_space(struct rd_dev *rd_dev, int prot_length)
+{
+ struct rd_dev_sg_table *sg_table;
+ u32 total_sg_needed, sg_tables;
+ u32 max_sg_per_table = (RD_MAX_ALLOCATION_SIZE /
+ sizeof(struct scatterlist));
+ int rc;
+
+ if (rd_dev->rd_flags & RDF_NULLIO)
+ return 0;
+
+ total_sg_needed = rd_dev->rd_page_count / prot_length;
+
+ sg_tables = (total_sg_needed / max_sg_per_table) + 1;
+
+ sg_table = kzalloc(sg_tables * sizeof(struct rd_dev_sg_table),
GFP_KERNEL);
+ if (!sg_table) {
+ pr_err("Unable to allocate memory for Ramdisk protection"
+ " scatterlist tables\n");
+ return -ENOMEM;
+ }
+
+ rd_dev->sg_prot_array = sg_table;
+ rd_dev->sg_prot_count = sg_tables;
+
+ rc = rd_allocate_sgl_table(rd_dev, sg_table, total_sg_needed, 0xff);
+ if (rc)
+ return rc;
+
+ pr_debug("CORE_RD[%u] - Built Ramdisk Device ID: %u prot space of"
+" %u pages in %u tables\n", rd_dev->rd_host->rd_host_id,
+rd_dev->rd_dev_id, total_sg_needed, rd_dev->sg_prot_count);
+
+ return 0;
+}
+
static struct se_device *rd_alloc_device(struct se_hba *hba, const char *name)
{
struct rd_dev *rd_dev;
@@ -479,6 +534,23 @@ static sector_t rd_get_blocks(struct se_device *dev)
return blocks_long;
}
+static int rd_init_prot(struct se_device *dev)
+{
+ struct rd_dev *rd_dev = RD_DEV(dev);
+
+if (!dev->dev_attrib.pi_prot_type)
+ return 0;
+
+ return rd_build_prot_space(rd_dev, dev->prot_length);
+}
+
+static void rd_free_prot(struct se_device *dev)
+{
+ struct rd_dev *rd_dev = RD_DEV(dev);
+
+ rd_release_prot_space(rd_dev);
+}
+
static struct sbc_ops rd_sbc_ops = {
.execute_rw = rd_execute_rw,
};
@@ -504,6 +576,8 @@ static struct se_subsystem_api rd_mcp_template = {
.show_configfs_dev_params = rd_show_configfs_dev_params,
.get_device_type= sbc_get_device_type,
.get_blocks = rd_get_blocks,
+ .init_prot = rd_init_prot,
+ .free_prot = rd_free_prot,
};
int __init rd_module_init(void)
diff --git a/drivers/target/target_core_rd.h b/drivers/target/target_core_rd.h
index 1789d1e..cc46a6a 100644
--- a/drivers/target/target_core_rd.h
+++ b/drivers/target/target_core_rd.h
@@ -33,8 +33,12 @@ struct rd_dev {
u32 rd_page_count;
/* Number of SG tables in sg_table_array */
u32 sg_table_count;
+ /* Number of SG tables in sg_prot_array */
+ u32 sg_prot_count;
/* Array of rd_dev_sg_table_t containing scatterlists */
struct rd_dev_sg_table *sg_table_array;
+ /* Array of rd_dev_sg_table containing protection scatterlists */
+ struct rd_dev_sg_table *sg_prot_array;
/* Ramdisk HBA device is connected to */
struct rd_host *rd_host;
} cacheline_aligned;
--
1.7.10.4
--
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
[PATCH-v2 17/17] tcm_loop: Enable DIF/DIX modes in SCSI host LLD
From: Nicholas Bellinger
This patch updates tcm_loop_driver_probe() to set protection
information using scsi_host_set_prot() and scsi_host_set_guard(),
which currently enabled all modes of DIF/DIX protection, minus
DIX TYPE0.
Also, update tcm_loop_submission_work() to pass struct scsi_cmnd
related protection into target_submit_cmd_map_sgls() during CDB
dispatch.
Reviewed-by: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/loopback/tcm_loop.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/target/loopback/tcm_loop.c
b/drivers/target/loopback/tcm_loop.c
index 112b795..fadad7c 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -217,7 +217,8 @@ static void tcm_loop_submission_work(struct work_struct
*work)
scsi_bufflen(sc), tcm_loop_sam_attr(sc),
sc->sc_data_direction, 0,
scsi_sglist(sc), scsi_sg_count(sc),
- sgl_bidi, sgl_bidi_count, NULL, 0);
+ sgl_bidi, sgl_bidi_count,
+ scsi_prot_sglist(sc), scsi_prot_sg_count(sc));
if (rc < 0) {
set_host_byte(sc, DID_NO_CONNECT);
goto out_done;
@@ -462,7 +463,7 @@ static int tcm_loop_driver_probe(struct device *dev)
{
struct tcm_loop_hba *tl_hba;
struct Scsi_Host *sh;
- int error;
+ int error, host_prot;
tl_hba = to_tcm_loop_hba(dev);
@@ -486,6 +487,13 @@ static int tcm_loop_driver_probe(struct device *dev)
sh->max_channel = 0;
sh->max_cmd_len = TL_SCSI_MAX_CMD_LEN;
+ host_prot = SHOST_DIF_TYPE1_PROTECTION | SHOST_DIF_TYPE2_PROTECTION |
+ SHOST_DIF_TYPE3_PROTECTION | SHOST_DIX_TYPE1_PROTECTION |
+ SHOST_DIX_TYPE2_PROTECTION | SHOST_DIX_TYPE3_PROTECTION;
+
+ scsi_host_set_prot(sh, host_prot);
+ scsi_host_set_guard(sh, SHOST_DIX_GUARD_CRC);
+
error = scsi_add_host(sh, _hba->dev);
if (error) {
pr_err("%s: scsi_add_host failed\n", __func__);
--
1.7.10.4
--
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 12/17] target/file: Add DIF protection init/format support
From: Nicholas Bellinger
This patch adds support for DIF protection init/format support into
the FILEIO backend.
It involves using a seperate $FILE.protection for storing PI that is
opened via fd_init_prot() using the common pi_prot_type attribute.
The actual formatting of the protection is done via fd_format_prot()
using the common pi_prot_format attribute, that will populate the
initial PI data based upon the currently configured pi_prot_type.
Based on original FILEIO code from Sagi.
v1 changes:
- Fix sparse warnings in fd_init_format_buf (Fengguang)
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_file.c | 137 +
drivers/target/target_core_file.h |4 ++
2 files changed, 141 insertions(+)
diff --git a/drivers/target/target_core_file.c
b/drivers/target/target_core_file.c
index 0e34cda..119d519 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -700,6 +700,140 @@ static sector_t fd_get_blocks(struct se_device *dev)
dev->dev_attrib.block_size);
}
+static int fd_init_prot(struct se_device *dev)
+{
+ struct fd_dev *fd_dev = FD_DEV(dev);
+ struct file *prot_file, *file = fd_dev->fd_file;
+ struct inode *inode;
+ int ret, flags = O_RDWR | O_CREAT | O_LARGEFILE | O_DSYNC;
+ char buf[FD_MAX_DEV_PROT_NAME];
+
+ if (!file) {
+ pr_err("Unable to locate fd_dev->fd_file\n");
+ return -ENODEV;
+ }
+
+ inode = file->f_mapping->host;
+ if (S_ISBLK(inode->i_mode)) {
+ pr_err("FILEIO Protection emulation only supported on"
+ " !S_ISBLK\n");
+ return -ENOSYS;
+ }
+
+ if (fd_dev->fbd_flags & FDBD_HAS_BUFFERED_IO_WCE)
+ flags &= ~O_DSYNC;
+
+ snprintf(buf, FD_MAX_DEV_PROT_NAME, "%s.protection",
+fd_dev->fd_dev_name);
+
+ prot_file = filp_open(buf, flags, 0600);
+ if (IS_ERR(prot_file)) {
+ pr_err("filp_open(%s) failed\n", buf);
+ ret = PTR_ERR(prot_file);
+ return ret;
+ }
+ fd_dev->fd_prot_file = prot_file;
+
+ return 0;
+}
+
+static void fd_init_format_buf(struct se_device *dev, unsigned char *buf,
+ u32 unit_size, u32 *ref_tag, u16 app_tag,
+ bool inc_reftag)
+{
+ unsigned char *p = buf;
+ int i;
+
+ for (i = 0; i < unit_size; i += dev->prot_length) {
+ *((u16 *)[0]) = 0x;
+ *((__be16 *)[2]) = cpu_to_be16(app_tag);
+ *((__be32 *)[4]) = cpu_to_be32(*ref_tag);
+
+ if (inc_reftag)
+ (*ref_tag)++;
+
+ p += dev->prot_length;
+ }
+}
+
+static int fd_format_prot(struct se_device *dev)
+{
+ struct fd_dev *fd_dev = FD_DEV(dev);
+ struct file *prot_fd = fd_dev->fd_prot_file;
+ sector_t prot_length, prot;
+ unsigned char *buf;
+ loff_t pos = 0;
+ u32 ref_tag = 0;
+ int unit_size = FDBD_FORMAT_UNIT_SIZE * dev->dev_attrib.block_size;
+ int rc, ret = 0, size, len;
+ bool inc_reftag = false;
+
+ if (!dev->dev_attrib.pi_prot_type) {
+ pr_err("Unable to format_prot while pi_prot_type == 0\n");
+ return -ENODEV;
+ }
+ if (!prot_fd) {
+ pr_err("Unable to locate fd_dev->fd_prot_file\n");
+ return -ENODEV;
+ }
+
+ switch (dev->dev_attrib.pi_prot_type) {
+ case TARGET_DIF_TYPE3_PROT:
+ ref_tag = 0x;
+ break;
+ case TARGET_DIF_TYPE2_PROT:
+ case TARGET_DIF_TYPE1_PROT:
+ inc_reftag = true;
+ break;
+ default:
+ break;
+ }
+
+ buf = vzalloc(unit_size);
+ if (!buf) {
+ pr_err("Unable to allocate FILEIO prot buf\n");
+ return -ENOMEM;
+ }
+
+ prot_length = (dev->transport->get_blocks(dev) + 1) * dev->prot_length;
+ size = prot_length;
+
+ pr_debug("Using FILEIO prot_length: %llu\n",
+(unsigned long long)prot_length);
+
+ for (prot = 0; prot < prot_length; prot += unit_size) {
+
+ fd_init_format_buf(dev, buf, unit_size, _tag, 0x,
+ inc_reftag);
+
+ len = min(unit_size, size);
+
+ rc = kernel_write(prot_fd, buf, len, pos);
+ if (rc != len) {
+ pr_err("vfs_write to prot file failed: %d\n", rc);
+ ret = -ENODEV;
+ goto out;
+ }
+ pos += len;
+ size -= len;
+ }
+
+out:
+ vfree(buf);
+ return ret;
+}
+
+static void fd_free_prot(struct se_device *dev)
+{
+
[PATCH-v2 13/17] target/file: Add DIF protection support to fd_execute_rw
From: Nicholas Bellinger
This patch adds support for DIF protection into fd_execute_rw() code
for WRITE/READ I/O using sbc_dif_verify_[write,read]() logic.
It adds fd_do_prot_rw() for handling interface with FILEIO PI, and
uses a locally allocated fd_prot->prot_buf + fd_prot->prot_sg for
interacting with SBC DIF verify emulation code.
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_file.c | 119 -
drivers/target/target_core_file.h |5 ++
2 files changed, 123 insertions(+), 1 deletion(-)
diff --git a/drivers/target/target_core_file.c
b/drivers/target/target_core_file.c
index 119d519..aaba7c5 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -257,6 +257,72 @@ static void fd_free_device(struct se_device *dev)
kfree(fd_dev);
}
+static int fd_do_prot_rw(struct se_cmd *cmd, struct fd_prot *fd_prot,
+int is_write)
+{
+ struct se_device *se_dev = cmd->se_dev;
+ struct fd_dev *dev = FD_DEV(se_dev);
+ struct file *prot_fd = dev->fd_prot_file;
+ struct scatterlist *sg;
+ loff_t pos = (cmd->t_task_lba * se_dev->prot_length);
+ unsigned char *buf;
+ u32 prot_size, len, size;
+ int rc, ret = 1, i;
+
+ prot_size = (cmd->data_length / se_dev->dev_attrib.block_size) *
+se_dev->prot_length;
+
+ if (!is_write) {
+ fd_prot->prot_buf = vzalloc(prot_size);
+ if (!fd_prot->prot_buf) {
+ pr_err("Unable to allocate fd_prot->prot_buf\n");
+ return -ENOMEM;
+ }
+ buf = fd_prot->prot_buf;
+
+ fd_prot->prot_sg_nents = cmd->t_prot_nents;
+ fd_prot->prot_sg = kzalloc(sizeof(struct scatterlist) *
+ fd_prot->prot_sg_nents, GFP_KERNEL);
+ if (!fd_prot->prot_sg) {
+ pr_err("Unable to allocate fd_prot->prot_sg\n");
+ vfree(fd_prot->prot_buf);
+ return -ENOMEM;
+ }
+ size = prot_size;
+
+ for_each_sg(fd_prot->prot_sg, sg, fd_prot->prot_sg_nents, i) {
+
+ len = min_t(u32, PAGE_SIZE, size);
+ sg_set_buf(sg, buf, len);
+ size -= len;
+ buf += len;
+ }
+ }
+
+ if (is_write) {
+ rc = kernel_write(prot_fd, fd_prot->prot_buf, prot_size, pos);
+ if (rc < 0 || prot_size != rc) {
+ pr_err("kernel_write() for fd_do_prot_rw failed:"
+ " %d\n", rc);
+ ret = -EINVAL;
+ }
+ } else {
+ rc = kernel_read(prot_fd, pos, fd_prot->prot_buf, prot_size);
+ if (rc < 0) {
+ pr_err("kernel_read() for fd_do_prot_rw failed:"
+ " %d\n", rc);
+ ret = -EINVAL;
+ }
+ }
+
+ if (is_write || ret < 0) {
+ kfree(fd_prot->prot_sg);
+ vfree(fd_prot->prot_buf);
+ }
+
+ return ret;
+}
+
static int fd_do_rw(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents, int is_write)
{
@@ -551,6 +617,8 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents,
enum dma_data_direction data_direction)
{
struct se_device *dev = cmd->se_dev;
+ struct fd_prot fd_prot;
+ sense_reason_t rc;
int ret = 0;
/*
@@ -558,8 +626,48 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents,
* physical memory addresses to struct iovec virtual memory.
*/
if (data_direction == DMA_FROM_DEVICE) {
+ memset(_prot, 0, sizeof(struct fd_prot));
+
+ if (cmd->prot_type) {
+ ret = fd_do_prot_rw(cmd, _prot, false);
+ if (ret < 0)
+ return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
+ }
+
ret = fd_do_rw(cmd, sgl, sgl_nents, 0);
+
+ if (ret > 0 && cmd->prot_type) {
+ u32 sectors = cmd->data_length /
dev->dev_attrib.block_size;
+
+ rc = sbc_dif_verify_read(cmd, cmd->t_task_lba, sectors,
+0, fd_prot.prot_sg, 0);
+ if (rc) {
+ kfree(fd_prot.prot_sg);
+ vfree(fd_prot.prot_buf);
+ return rc;
+ }
+ kfree(fd_prot.prot_sg);
+ vfree(fd_prot.prot_buf);
+ }
} else {
+
[PATCH-v2 16/17] target/rd: Add DIF protection into rd_execute_rw
From: Nicholas Bellinger
This patch adds support for DIF protection into rd_execute_rw() code
for WRITE/READ I/O using sbc_dif_verify_[write,read]() logic.
It also adds rd_get_prot_table() for locating protection SGLs
assoicated with the ramdisk backend device.
v2 changes:
- Make rd_execute_rw() to u32 sectors count instead of sector_t
- Drop SCF_PROT usage
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_rd.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index 660961d..66a5aba 100644
--- a/drivers/target/target_core_rd.c
+++ b/drivers/target/target_core_rd.c
@@ -356,6 +356,26 @@ static struct rd_dev_sg_table *rd_get_sg_table(struct
rd_dev *rd_dev, u32 page)
return NULL;
}
+static struct rd_dev_sg_table *rd_get_prot_table(struct rd_dev *rd_dev, u32
page)
+{
+ struct rd_dev_sg_table *sg_table;
+ u32 i, sg_per_table = (RD_MAX_ALLOCATION_SIZE /
+ sizeof(struct scatterlist));
+
+ i = page / sg_per_table;
+ if (i < rd_dev->sg_prot_count) {
+ sg_table = _dev->sg_prot_array[i];
+ if ((sg_table->page_start_offset <= page) &&
+(sg_table->page_end_offset >= page))
+ return sg_table;
+ }
+
+ pr_err("Unable to locate struct prot rd_dev_sg_table for page: %u\n",
+ page);
+
+ return NULL;
+}
+
static sense_reason_t
rd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
enum dma_data_direction data_direction)
@@ -370,6 +390,7 @@ rd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents,
u32 rd_page;
u32 src_len;
u64 tmp;
+ sense_reason_t rc;
if (dev->rd_flags & RDF_NULLIO) {
target_complete_cmd(cmd, SAM_STAT_GOOD);
@@ -392,6 +413,28 @@ rd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents,
data_direction == DMA_FROM_DEVICE ? "Read" : "Write",
cmd->t_task_lba, rd_size, rd_page, rd_offset);
+ if (cmd->prot_type && data_direction == DMA_TO_DEVICE) {
+ struct rd_dev_sg_table *prot_table;
+ struct scatterlist *prot_sg;
+ u32 sectors = cmd->data_length / se_dev->dev_attrib.block_size;
+ u32 prot_offset, prot_page;
+
+ tmp = cmd->t_task_lba * se_dev->prot_length;
+ prot_offset = do_div(tmp, PAGE_SIZE);
+ prot_page = tmp;
+
+ prot_table = rd_get_prot_table(dev, prot_page);
+ if (!prot_table)
+ return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
+
+ prot_sg = _table->sg_table[prot_page -
prot_table->page_start_offset];
+
+ rc = sbc_dif_verify_write(cmd, cmd->t_task_lba, sectors, 0,
+ prot_sg, prot_offset);
+ if (rc)
+ return rc;
+ }
+
src_len = PAGE_SIZE - rd_offset;
sg_miter_start(, sgl, sgl_nents,
data_direction == DMA_FROM_DEVICE ?
@@ -453,6 +496,28 @@ rd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl,
u32 sgl_nents,
}
sg_miter_stop();
+ if (cmd->prot_type && data_direction == DMA_FROM_DEVICE) {
+ struct rd_dev_sg_table *prot_table;
+ struct scatterlist *prot_sg;
+ u32 sectors = cmd->data_length / se_dev->dev_attrib.block_size;
+ u32 prot_offset, prot_page;
+
+ tmp = cmd->t_task_lba * se_dev->prot_length;
+ prot_offset = do_div(tmp, PAGE_SIZE);
+ prot_page = tmp;
+
+ prot_table = rd_get_prot_table(dev, prot_page);
+ if (!prot_table)
+ return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
+
+ prot_sg = _table->sg_table[prot_page -
prot_table->page_start_offset];
+
+ rc = sbc_dif_verify_read(cmd, cmd->t_task_lba, sectors, 0,
+prot_sg, prot_offset);
+ if (rc)
+ return rc;
+ }
+
target_complete_cmd(cmd, SAM_STAT_GOOD);
return 0;
}
--
1.7.10.4
--
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 03/17] target/sbc: Add DIF setup in sbc_check_prot + sbc_parse_cdb
From: Nicholas Bellinger
This patch adds sbc_check_prot() for performing various DIF
related CDB sanity checks, along with setting cmd->prot_type
once sanity checks have passed.
Also, add calls in sbc_parse_cdb() for READ_[10,12,16] +
WRITE_[10,12,16] to perform DIF sanity checking.
v2 changes:
- Make sbc_check_prot defined as static (Fengguang + Wei)
- Remove unprotected READ/WRITE warning (mkp)
- Populate cmd->prot_type + friends (Sagi)
- Drop SCF_PROT usage
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_sbc.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 6863dbe..91a92f3 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -563,6 +563,44 @@ sbc_compare_and_write(struct se_cmd *cmd)
return TCM_NO_SENSE;
}
+static bool
+sbc_check_prot(struct se_device *dev, struct se_cmd *cmd, unsigned char *cdb,
+ u32 sectors)
+{
+ if (!cmd->t_prot_sg || !cmd->t_prot_nents)
+ return true;
+
+ switch (dev->dev_attrib.pi_prot_type) {
+ case TARGET_DIF_TYPE3_PROT:
+ if (!(cdb[1] & 0xe0))
+ return true;
+
+ cmd->reftag_seed = 0x;
+ break;
+ case TARGET_DIF_TYPE2_PROT:
+ if (cdb[1] & 0xe0)
+ return false;
+
+ cmd->reftag_seed = cmd->t_task_lba;
+ break;
+ case TARGET_DIF_TYPE1_PROT:
+ if (!(cdb[1] & 0xe0))
+ return true;
+
+ cmd->reftag_seed = cmd->t_task_lba;
+ break;
+ case TARGET_DIF_TYPE0_PROT:
+ default:
+ return true;
+ }
+
+ cmd->prot_type = dev->dev_attrib.pi_prot_type;
+ cmd->prot_length = dev->prot_length * sectors;
+ cmd->prot_handover = PROT_SEPERATED;
+
+ return true;
+}
+
sense_reason_t
sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
{
@@ -583,6 +621,10 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
case READ_10:
sectors = transport_get_sectors_10(cdb);
cmd->t_task_lba = transport_lba_32(cdb);
+
+ if (!sbc_check_prot(dev, cmd, cdb, sectors))
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+
cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB;
cmd->execute_rw = ops->execute_rw;
cmd->execute_cmd = sbc_execute_rw;
@@ -590,6 +632,10 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
case READ_12:
sectors = transport_get_sectors_12(cdb);
cmd->t_task_lba = transport_lba_32(cdb);
+
+ if (!sbc_check_prot(dev, cmd, cdb, sectors))
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+
cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB;
cmd->execute_rw = ops->execute_rw;
cmd->execute_cmd = sbc_execute_rw;
@@ -597,6 +643,10 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
case READ_16:
sectors = transport_get_sectors_16(cdb);
cmd->t_task_lba = transport_lba_64(cdb);
+
+ if (!sbc_check_prot(dev, cmd, cdb, sectors))
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+
cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB;
cmd->execute_rw = ops->execute_rw;
cmd->execute_cmd = sbc_execute_rw;
@@ -612,6 +662,10 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
case WRITE_VERIFY:
sectors = transport_get_sectors_10(cdb);
cmd->t_task_lba = transport_lba_32(cdb);
+
+ if (!sbc_check_prot(dev, cmd, cdb, sectors))
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+
if (cdb[1] & 0x8)
cmd->se_cmd_flags |= SCF_FUA;
cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB;
@@ -621,6 +675,10 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
case WRITE_12:
sectors = transport_get_sectors_12(cdb);
cmd->t_task_lba = transport_lba_32(cdb);
+
+ if (!sbc_check_prot(dev, cmd, cdb, sectors))
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+
if (cdb[1] & 0x8)
cmd->se_cmd_flags |= SCF_FUA;
cmd->se_cmd_flags |= SCF_SCSI_DATA_CDB;
@@ -630,6 +688,10 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
case WRITE_16:
sectors = transport_get_sectors_16(cdb);
cmd->t_task_lba = transport_lba_64(cdb);
+
+ if (!sbc_check_prot(dev, cmd, cdb, sectors))
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+
if
[PATCH-v2 05/17] target/spc: Add protection bit to standard INQUIRY output
From: Nicholas Bellinger This patch updates spc_emulate_inquiry_std() to set the PROTECT bit when DIF emulation is enabled by the backend device. Reviewed-by: Martin K. Petersen Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger --- drivers/target/target_core_spc.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c index 279d260..4178c2a 100644 --- a/drivers/target/target_core_spc.c +++ b/drivers/target/target_core_spc.c @@ -100,6 +100,11 @@ spc_emulate_inquiry_std(struct se_cmd *cmd, unsigned char *buf) */ if (dev->dev_attrib.emulate_3pc) buf[5] |= 0x8; + /* +* Set Protection (PROTECT) bit when DIF has been enabled. +*/ + if (dev->dev_attrib.pi_prot_type) + buf[5] |= 0x1; buf[7] = 0x2; /* CmdQue=1 */ -- 1.7.10.4 -- 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 09/17] target/configfs: Expose protection device attributes
From: Nicholas Bellinger
This patch adds support for exposing DIF protection device
attributes via configfs. This includes:
pi_prot_type: Protection Type (0, 1, 3 currently support)
pi_prot_format: Protection Format Operation (FILEIO only)
Within se_dev_set_pi_prot_type() it also adds the se_subsystem_api
device callbacks to setup per device protection information.
v2 changes:
- Drop pi_guard_type + pi_prot_version related code (MKP)
- Add pi_prot_format logic (Sagi)
- Add ->free_prot callback in target_free_device
- Add hw_pi_prot_type read-only attribute
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_configfs.c | 12 +
drivers/target/target_core_device.c | 89 +
drivers/target/target_core_internal.h |2 +
3 files changed, 103 insertions(+)
diff --git a/drivers/target/target_core_configfs.c
b/drivers/target/target_core_configfs.c
index 5cf6135..f0e85b1 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -643,6 +643,15 @@ SE_DEV_ATTR(emulate_caw, S_IRUGO | S_IWUSR);
DEF_DEV_ATTRIB(emulate_3pc);
SE_DEV_ATTR(emulate_3pc, S_IRUGO | S_IWUSR);
+DEF_DEV_ATTRIB(pi_prot_type);
+SE_DEV_ATTR(pi_prot_type, S_IRUGO | S_IWUSR);
+
+DEF_DEV_ATTRIB_RO(hw_pi_prot_type);
+SE_DEV_ATTR_RO(hw_pi_prot_type);
+
+DEF_DEV_ATTRIB(pi_prot_format);
+SE_DEV_ATTR(pi_prot_format, S_IRUGO | S_IWUSR);
+
DEF_DEV_ATTRIB(enforce_pr_isids);
SE_DEV_ATTR(enforce_pr_isids, S_IRUGO | S_IWUSR);
@@ -702,6 +711,9 @@ static struct configfs_attribute
*target_core_dev_attrib_attrs[] = {
_core_dev_attrib_emulate_tpws.attr,
_core_dev_attrib_emulate_caw.attr,
_core_dev_attrib_emulate_3pc.attr,
+ _core_dev_attrib_pi_prot_type.attr,
+ _core_dev_attrib_hw_pi_prot_type.attr,
+ _core_dev_attrib_pi_prot_format.attr,
_core_dev_attrib_enforce_pr_isids.attr,
_core_dev_attrib_is_nonrot.attr,
_core_dev_attrib_emulate_rest_reord.attr,
diff --git a/drivers/target/target_core_device.c
b/drivers/target/target_core_device.c
index 3244058..883099e 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -918,6 +918,90 @@ int se_dev_set_emulate_3pc(struct se_device *dev, int flag)
return 0;
}
+int se_dev_set_pi_prot_type(struct se_device *dev, int flag)
+{
+ int rc, old_prot = dev->dev_attrib.pi_prot_type;
+
+ if (flag != 0 && flag != 1 && flag != 2 && flag != 3) {
+ pr_err("Illegal value %d for pi_prot_type\n", flag);
+ return -EINVAL;
+ }
+ if (flag == 2) {
+ pr_err("DIF TYPE2 protection currently not supported\n");
+ return -ENOSYS;
+ }
+ if (dev->dev_attrib.hw_pi_prot_type) {
+ pr_warn("DIF protection enabled on underlying hardware,"
+ " ignoring\n");
+ return 0;
+ }
+ if (!dev->transport->init_prot || !dev->transport->free_prot) {
+ pr_err("DIF protection not supported by backend: %s\n",
+ dev->transport->name);
+ return -ENOSYS;
+ }
+ if (!(dev->dev_flags & DF_CONFIGURED)) {
+ pr_err("DIF protection requires device to be configured\n");
+ return -ENODEV;
+ }
+ if (dev->export_count) {
+ pr_err("dev[%p]: Unable to change SE Device PROT type while"
+ " export_count is %d\n", dev, dev->export_count);
+ return -EINVAL;
+ }
+
+ dev->dev_attrib.pi_prot_type = flag;
+
+ if (flag && !old_prot) {
+ rc = dev->transport->init_prot(dev);
+ if (rc) {
+ dev->dev_attrib.pi_prot_type = old_prot;
+ return rc;
+ }
+
+ } else if (!flag && old_prot) {
+ dev->transport->free_prot(dev);
+ }
+ pr_debug("dev[%p]: SE Device Protection Type: %d\n", dev, flag);
+
+ return 0;
+}
+
+int se_dev_set_pi_prot_format(struct se_device *dev, int flag)
+{
+ int rc;
+
+ if (!flag)
+ return 0;
+
+ if (flag != 1) {
+ pr_err("Illegal value %d for pi_prot_format\n", flag);
+ return -EINVAL;
+ }
+ if (!dev->transport->format_prot) {
+ pr_err("DIF protection format not supported by backend %s\n",
+ dev->transport->name);
+ return -ENOSYS;
+ }
+ if (!(dev->dev_flags & DF_CONFIGURED)) {
+ pr_err("DIF protection format requires device to be
configured\n");
+ return -ENODEV;
+ }
+ if (dev->export_count) {
+ pr_err("dev[%p]: Unable to format SE Device PROT type while"
+ " export_count is %d\n", dev,
[PATCH-v2 00/17] target: Add support for DIF Type1+Type3 emulation + passthrough
From: Nicholas Bellinger Hi MKP & Co, This -v2 series contains support for target mode DIF Type1+Type3 emulation within target core, FILEIO, and RAMDISK_MCP device backends, BIP passthrough of T10 PI within IBLOCK device backends, and DIF/DIX host support in the tcm_loop fabric driver. DIF emulation is enabled via a new 'pi_prot_type' device attribute within configfs for FILEIO + RAMDISK_MCP, which is set after initial device configuration and before target fabric LUN export occurs. For IBLOCK backends, protection support is automatically detected via struct blk_integrity at configuration time, and no additional end-user setup is required. For FILEIO backends, format of protection information is exposed via a new 'pi_prot_format' device attribute, that is used during initial configuration to format a new $FILENAME.protection file containing DIF Type1/Type3 style metadata. Also, the DIF read/write verify emulation has been made generic enough so it can be used by other backend drivers (eg: FILEIO), as well as Type4 (16-byte PI) in the near future. Here is the v1 -> v2 changelog: - Drop guard_type related definitions - Update target_prot_op + target_prot_ho definitions (Sagi) - Drop SCF_PROT + pi_prot_version flag - Add se_subsystem_api->format_prot() (Sagi) - Add hw_pi_prot_type device attribute - Make sbc_check_prot defined as static (Fengguang + Wei) - Remove unprotected READ/WRITE warning (mkp) - Populate cmd->prot_type + friends (Sagi) - Drop SCF_PROT usage - Select CRC_T10DIF for TARGET_CORE in Kconfig (Fengguang) - Drop IP checksum logic from sbc_dif_v1_verify (MKP) - Fix offset on app_tag = 0x in sbc_dif_verify_read() - Drop pi_guard_type + pi_prot_version related code (MKP) - Add pi_prot_format logic (Sagi) - Add ->free_prot callback in target_free_device - Add hw_pi_prot_type read-only attribute - Add target/iblock blk_integrity + BIP passthrough - Add target/file DIF protection init/format support - Add target/file DIF protection support to fd_execute_rw - Drop unused sg_table from rd_release_device_space (Wei) - Drop unused sg_table from rd_release_prot_space (Wei) - Drop rd_release_prot_space call from rd_free_device - Make rd_execute_rw() to u32 sectors count instead of sector_t At this point the main TODO item remaining for v3.14 code is to determine how best to propigate App/Guard/Reference Tag VERIFY failures back up into IBLOCK device backend code. MKP has an idea how to go about doing this that will be appearing as a seperate SCSI-core + IBLOCK patch. Thank you, --nab Nicholas Bellinger (17): target: Add DIF related base definitions target: Add DIF CHECK_CONDITION ASC/ASCQ exception cases target/sbc: Add DIF setup in sbc_check_prot + sbc_parse_cdb target/sbc: Add DIF TYPE1+TYPE3 read/write verify emulation target/spc: Add protection bit to standard INQUIRY output target/spc: Add protection related bits to INQUIRY EVPD=0x86 target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY_16 target/spc: Expose ATO bit in control mode page target/configfs: Expose protection device attributes target: Add protection SGLs to target_submit_cmd_map_sgls target/iblock: Add blk_integrity + BIP passthrough support target/file: Add DIF protection init/format support target/file: Add DIF protection support to fd_execute_rw target/rd: Refactor rd_build_device_space + rd_release_device_space target/rd: Add support for protection SGL setup + release target/rd: Add DIF protection into rd_execute_rw tcm_loop: Enable DIF/DIX modes in SCSI host LLD drivers/target/Kconfig |2 + drivers/target/loopback/tcm_loop.c | 12 +- drivers/target/target_core_configfs.c | 12 ++ drivers/target/target_core_device.c| 89 +++ drivers/target/target_core_file.c | 256 +++- drivers/target/target_core_file.h |9 ++ drivers/target/target_core_iblock.c| 91 +++- drivers/target/target_core_internal.h |2 + drivers/target/target_core_rd.c| 252 +-- drivers/target/target_core_rd.h|4 + drivers/target/target_core_sbc.c | 245 ++ drivers/target/target_core_spc.c | 27 drivers/target/target_core_transport.c | 46 +- drivers/vhost/scsi.c |2 +- include/target/target_core_backend.h |7 + include/target/target_core_base.h | 47 ++ include/target/target_core_fabric.h|3 +- 17 files changed, 1052 insertions(+), 54 deletions(-) -- 1.7.10.4 -- 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 01/17] target: Add DIF related base definitions
From: Nicholas Bellinger
This patch adds DIF related definitions to target_core_base.h
that includes enums for target_prot_op + target_prot_type +
target_prot_version + target_guard_type + target_pi_error.
Also included is struct se_dif_v1_tuple, along with changes
to struct se_cmd, struct se_dev_attrib, and struct se_device.
Also, add new se_subsystem_api->[init,format,free]_prot() callers
used by target core code to setup backend specific protection
information after the device has been configured.
Enums taken from Sagi Grimberg's original patch.
v2 changes:
- Drop guard_type related definitions
- Update target_prot_op + target_prot_ho definitions (Sagi)
- Drop SCF_PROT + pi_prot_version flag
- Add se_subsystem_api->format_prot() (Sagi)
- Add hw_pi_prot_type device attribute
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
include/target/target_core_backend.h |3 +++
include/target/target_core_base.h| 44 ++
2 files changed, 47 insertions(+)
diff --git a/include/target/target_core_backend.h
b/include/target/target_core_backend.h
index 39e0114..0dc2745 100644
--- a/include/target/target_core_backend.h
+++ b/include/target/target_core_backend.h
@@ -41,6 +41,9 @@ struct se_subsystem_api {
unsigned int (*get_io_opt)(struct se_device *);
unsigned char *(*get_sense_buffer)(struct se_cmd *);
bool (*get_write_cache)(struct se_device *);
+ int (*init_prot)(struct se_device *);
+ int (*format_prot)(struct se_device *);
+ void (*free_prot)(struct se_device *);
};
struct sbc_ops {
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index dd87ab4..d98048b 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -435,6 +435,34 @@ struct se_tmr_req {
struct list_headtmr_list;
};
+enum target_prot_op {
+ TARGET_PROT_NORMAL = 0,
+ TARGET_PROT_DIN_INSERT,
+ TARGET_PROT_DOUT_INSERT,
+ TARGET_PROT_DIN_STRIP,
+ TARGET_PROT_DOUT_STRIP,
+ TARGET_PROT_DIN_PASS,
+ TARGET_PROT_DOUT_PASS,
+};
+
+enum target_prot_ho {
+ PROT_SEPERATED,
+ PROT_INTERLEAVED,
+};
+
+enum target_prot_type {
+ TARGET_DIF_TYPE0_PROT,
+ TARGET_DIF_TYPE1_PROT,
+ TARGET_DIF_TYPE2_PROT,
+ TARGET_DIF_TYPE3_PROT,
+};
+
+struct se_dif_v1_tuple {
+ __be16 guard_tag;
+ __be16 app_tag;
+ __be32 ref_tag;
+};
+
struct se_cmd {
/* SAM response code being sent to initiator */
u8 scsi_status;
@@ -519,6 +547,17 @@ struct se_cmd {
/* Used for lun->lun_ref counting */
boollun_ref_active;
+
+ /* DIF related members */
+ enum target_prot_op prot_op;
+ enum target_prot_type prot_type;
+ u32 prot_length;
+ u32 reftag_seed;
+ struct scatterlist *t_prot_sg;
+ unsigned intt_prot_nents;
+ enum target_prot_ho prot_handover;
+ sense_reason_t pi_err;
+ u32 block_num;
};
struct se_ua {
@@ -629,6 +668,9 @@ struct se_dev_attrib {
int emulate_tpws;
int emulate_caw;
int emulate_3pc;
+ int pi_prot_format;
+ enum target_prot_type pi_prot_type;
+ enum target_prot_type hw_pi_prot_type;
int enforce_pr_isids;
int is_nonrot;
int emulate_rest_reord;
@@ -759,6 +801,8 @@ struct se_device {
/* Linked list for struct se_hba struct se_device list */
struct list_headdev_list;
struct se_lun xcopy_lun;
+ /* Protection Information */
+ int prot_length;
};
struct se_hba {
--
1.7.10.4
--
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/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}
On Friday, January 10 2014, Oleg Nesterov wrote: > So suppose that gdb does ptrace(PTRACE_SINGLESTEP) and the tracee > executes the "syscall" insn. What it should report? [...] > But what should syscall-exit do? Should it still report SIGSEGV as > it currently does, or should it report _SYSCALL_EXIT instead (if > PTRACE_O_SYSCALL_EXIT of course), or should it report both? Both only if _SYSCALL_EXIT is set. Otherwise, stick to the current behavior, I guess. Isn't it what my current patch does, by the way? I didn't test this scenario so I'm just guessing here... -- Sergio -- 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/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}
On Thursday, January 09 2014, Roland McGrath wrote: >> I won't argue, but it is not clear to me if this is really useful, >> given that the debugger can read the regs. > > I do see the utility of having a consistent machine-independent way to get > the syscall number from userspace. But note that this could be probably > accomplished with just a uapi header change, providing an inline or macro > to extract the syscall number from the regset data. (It was once the case > that there were some machines where the syscall number is not in any > register and has to be extracted by decoding the instruction. I'm not sure > if that is still an issue anywhere.) > > Also note that adding a separate copy of the syscall number introduces a > new wrinkle into the interface. This might be considered to be good, bad, > or indifferent, but I think it should at least be considered explicitly. > That is, at the entry stop the syscall number (when it's in a register) can > be changed via ptrace. So if the number is delivered via ptrace_message, > that's a separate copy of the original number that does not reflect any > changes made via ptrace--so it reflects what userland asked for, as opposed > to what the kernel actually acted on. > > I don't have a particular opinion about which way to go with that. > I just wanted all the issues (I'm aware of) to be considered. Hm, thanks for your insights. I don't really have a strong opinion here. I could say that I think ptrace should report the syscall that was originally called (and not the one that will effectively be called), but maybe that would sound like I am defending what I current have, heh... Anyway, one question that I'm having now is what currently happens. Guess I will take a look. Having said that, if adding the syscall number information to ptrace_message is too much controversial, I guess I will abandon this idea for now and just implement the notifications. -- Sergio -- 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: [BUG] Panic when booting
On 01/17/2014 01:42 AM, Paul Bolle wrote: On Fri, 2014-01-17 at 17:34 +0800, Madper Xie wrote: I meet following panic when I booting my HP Compad Elite 8300 Elite SFF desktop. [call trace here:] [0.569993] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [0.578269] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW3.13.0-rc8 #1 [0.585496] Hardware name: Hewlett-Packard HP Compaq Elite 8300 SFF/3397, BIOS K01 v02.05 05/07/2012 [0.594639] 880213125d70 815dd70e 817e8598 [0.602100] 880213125de8 815d72bb 0010 880213125df8 [0.609570] 880213125d98 880213125da0 880213125e08 0012 [0.617050] Call Trace: [0.619511] [] dump_stack+0x45/0x56 [0.624664] [] panic+0xc8/0x1d7 [0.629470] [] mount_block_root+0x2a1/0x2b0 [0.635309] [] mount_root+0x53/0x56 [0.640467] [] prepare_namespace+0x13c/0x174 [0.646392] [] kernel_init_freeable+0x218/0x22b [0.652578] [] ? do_early_param+0x88/0x88 [0.658245] [] ? rest_init+0x80/0x80 [0.663493] [] kernel_init+0xe/0x120 [0.668724] [] ret_from_fork+0x7c/0xb0 [0.674125] [] ? rest_init+0x80/0x80 [0.792437] Rebooting in 3 seconds.. [...] I can reproduce it 100%. Will do a bisect next monday if no one has clue. I'd double check my bootloader configuration and the initramfs (which you're probably using) if I'd encountered ab backtrace like that before bisecting. But we seem to be missing quite a bit of dmesg's output, so that's a bit of a guess... FWIW, I am getting the same panic if I build 3.13-rc8 with Ubuntu's config-3.11.0-15-generic after running "make oldnoconfig" on it. My own scaled down configuration from an earlier kernel works just fine. I thought it was operator error, went back to my old configuration, and didn't think about it anymore, but maybe there is something fishy in the resulting configuration. Guenter -- 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/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}
On Monday, January 13 2014, Denys Vlasenko wrote:
> On Mon, Jan 6, 2014 at 11:52 PM, Sergio Durigan Junior
> wrote:
>> The other nice thing that I have implemented is the ability to obtain
>> the syscall number related to the event by using PTRACE_GET_EVENTMSG.
>> This way, we don't need to inspect registers anymore when we want to
>> know which syscall is responsible for this or that event.
>
> OTOH, by fetching registers using just one ptrace call you
> get a lot more data.
> So, this isn't *that* useful -- the debuggers already know how to fetch
> and interpret regs - but it is also a cheap change. Why not?
Thanks for the review, and sorry for the delay in answering.
I hope I have already touched this point in my other message to Oleg,
about making a single interface for all targets supported by the Linux
kernel and GDB, thus enabling them to obtain this information directly
from Linux instead of having to go and fetch the regs by themselves.
>> -static inline int ptrace_report_syscall(struct pt_regs *regs)
>> +static inline int ptrace_report_syscall(struct pt_regs *regs, int entry,
>> + unsigned int sysno)
>
>
> This function looks ripe for de-inlining.
Done.
>> /* Wait extended result codes for the above trace options. */
>> -#define PTRACE_EVENT_FORK 1
>> -#define PTRACE_EVENT_VFORK 2
>> -#define PTRACE_EVENT_CLONE 3
>> -#define PTRACE_EVENT_EXEC 4
>> -#define PTRACE_EVENT_VFORK_DONE5
>> -#define PTRACE_EVENT_EXIT 6
>> -#define PTRACE_EVENT_SECCOMP 7
>> +#define PTRACE_EVENT_FORK 1
>> +#define PTRACE_EVENT_VFORK 2
>> +#define PTRACE_EVENT_CLONE 3
>> +#define PTRACE_EVENT_EXEC 4
>> +#define PTRACE_EVENT_VFORK_DONE5
>> +#define PTRACE_EVENT_EXIT 6
>> +#define PTRACE_EVENT_SECCOMP 7
>> +#define PTRACE_EVENT_SYSCALL_ENTER 8
>> +#define PTRACE_EVENT_SYSCALL_EXIT 9
>> +
>> /* Extended result codes which enabled by means other than options. */
>> #define PTRACE_EVENT_STOP 128
>>
>> @@ -87,11 +90,13 @@ struct ptrace_peeksiginfo_args {
>> #define PTRACE_O_TRACEVFORKDONE(1 << PTRACE_EVENT_VFORK_DONE)
>> #define PTRACE_O_TRACEEXIT (1 << PTRACE_EVENT_EXIT)
>> #define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)
>> +#define PTRACE_O_SYSCALL_ENTER (1 << PTRACE_EVENT_SYSCALL_ENTER)
>> +#define PTRACE_O_SYSCALL_EXIT (1 << PTRACE_EVENT_SYSCALL_EXIT)
>>
>> /* eventless options */
>> #define PTRACE_O_EXITKILL (1 << 20)
>>
>> -#define PTRACE_O_MASK (0x00ff | PTRACE_O_EXITKILL)
>> +#define PTRACE_O_MASK (0x0fff | PTRACE_O_EXITKILL)
>
>
> You added just two bits, why did you extend the mask by four bits?
> IOW: shouldn't it be 0x3ff instead?
No particular reason, I just didn't give it much thinking. But thanks
for pointing that out, I've changed it.
--
Sergio
--
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 linux-next] net: batman-adv: use "__packed __aligned(2)" for each structure instead of "__packed(2)" region
On Saturday 18 January 2014 14:03:26 Antonio Quartulli wrote: > On 18/01/14 12:31, Chen Gang wrote: > > Unfortunately, not all compilers assumes the structures within a pack > > region also need be packed (e.g. metag), so need add a pack explicitly > > to satisfy all compilers. > > > > The related error (under metag with allmodconfig): > > MODPOST 2952 modules > > > > ERROR: "__compiletime_assert_431" [net/batman-adv/batman-adv.ko] > > undefined! > > ERROR: "__compiletime_assert_432" [net/batman-adv/batman-adv.ko] > > undefined! > > ERROR: "__compiletime_assert_429" [net/batman-adv/batman-adv.ko] > > undefined! > > ERROR: "__compiletime_assert_428" [net/batman-adv/batman-adv.ko] > > undefined! > > ERROR: "__compiletime_assert_423" [net/batman-adv/batman-adv.ko] > > undefined! > > > > Signed-off-by: Chen Gang > > David, what do you think about this change? > > > Can "__packed __aligned(2)" generate a different structure padding than > "#pragma pack(2)" ? > > I am not really sure about the difference between the two. But if we > have the possibility that the padding may change then this patch should > go into net, otherwise we will have a protocol compatibility problem > between 3.13 and 3.14. (Chen: sorry I didn't twig what you were referring to before about #pragma pack not working) It appears that the following gcc patch adds support for #pragma pack: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01115.html I gave it a quick spin on metag gcc (which is unfortunately stuck on an old version) and it seems to fix my simple test case so that #pragma pack(2) becomes equivalent to __packed __aligned(2) (for sizeof and __alignof__). However, the __packed and __aligned are linux specific macros to abstract compiler details, whereas #pragma pack appears to be a compiler-specific WIN32 style equivalent to GCC's __attribute__((packed)) and __attribute__((aligned(2))) (these are what __packed and __aligned use in compiler-gcc.h). Therefore I believe using the Linux abstractions is still more correct here. Cheers James signature.asc Description: This is a digitally signed message part.
[PATCH] block: Fix memory leak in rw_copy_check_uvector() handling
Fix a memory leak in the error handling path of function sg_io()
that is used during the processing of scsi ioctl. Memory already
allocated by rw_copy_check_uvector() needs to be freed correctly.
Detected by Coverity: CID 1128953.
Signed-off-by: Christian Engelmayer
---
block/scsi_ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 625e3e4..2648797 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -323,12 +323,14 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
if (hdr->iovec_count) {
size_t iov_data_len;
- struct iovec *iov;
+ struct iovec *iov = NULL;
ret = rw_copy_check_uvector(-1, hdr->dxferp, hdr->iovec_count,
0, NULL, );
- if (ret < 0)
+ if (ret < 0) {
+ kfree(iov);
goto out;
+ }
iov_data_len = ret;
ret = 0;
--
1.8.3.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: [RFC][PATCH] preempt: Debug for possible missed preemption checks
On Sun, 19 Jan 2014 11:52:53 +1100 Stephen Rothwell wrote: > Given that the merge window will probably open today or tomorrow, I would > prefer any new code not intended for 3.14 not be added to linux-next > until after v3.14-rc1 to avoid unneeded conflicts. If, however, Andrew > thinks it is still worth the (maybe minimal) pain, then fine. I'm not sure this is even intended for 3.15 either ;-) I'm fine with waiting, to keep from adding any extra pain just before a merge window. I guess the question is, is it OK to keep it in linux-next for 3.15 even though it may not even go into 3.15? Depends on how useful it proves to be. Perhaps it may require staying in linux-next till 3.16. Perhaps in order to keep merge windows from being an issue, I can add it at each -rc1, and remove it at -rc6, if it didn't catch any bugs. But as soon as it does catch a bug, we can say it's worth going into mainline. Does that sound fine with you? -- 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/
[for-next][PATCH] ktest: Add BISECT_TRIES to bisect test
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git
for-next
Head SHA1: 961d9caceea2d5350a15c17b7d3ffc24c08c9b09
Steven Rostedt (Red Hat) (1):
ktest: Add BISECT_TRIES to bisect test
tools/testing/ktest/ktest.pl| 24 ++--
tools/testing/ktest/sample.conf | 14 ++
2 files changed, 36 insertions(+), 2 deletions(-)
---
commit 961d9caceea2d5350a15c17b7d3ffc24c08c9b09
Author: Steven Rostedt (Red Hat)
Date: Sat Jan 18 19:52:13 2014 -0500
ktest: Add BISECT_TRIES to bisect test
For those cases that it takes several tries to hit a bug, it would be
useful for ktest.pl to try a test multiple times before it considers
the test as a pass. To accomplish this, BISECT_TRIES ktest config
option has been added. It is default to one, as most of the time a
bisect only needs to try a test once. But the user can now up this
to make ktest run a given test multiple times. The first failure
that is detected will set a bisect bad. It only repeats on success.
Note, as with all race bugs, there's no guarantee that if it succeeds,
it is really a good bisect. But it helps in case the bug is somewhat
reliable.
You can set BISECT_TRIES to zero, and all tests will be considered
good, unless you also set BISECT_MANUAL.
Suggested-by: "Paul E. McKenney"
Signed-off-by: Steven Rostedt
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 82006c2..a511d4a 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -41,6 +41,7 @@ my %default = (
"CLEAR_LOG"=> 0,
"BISECT_MANUAL"=> 0,
"BISECT_SKIP" => 1,
+"BISECT_TRIES" => 1,
"MIN_CONFIG_TYPE" => "boot",
"SUCCESS_LINE" => "login:",
"DETECT_TRIPLE_FAULT" => 1,
@@ -139,6 +140,7 @@ my $bisect_bad_commit = "";
my $reverse_bisect;
my $bisect_manual;
my $bisect_skip;
+my $bisect_tries;
my $config_bisect_good;
my $bisect_ret_good;
my $bisect_ret_bad;
@@ -276,6 +278,7 @@ my %option_map = (
"IGNORE_ERRORS"=> \$ignore_errors,
"BISECT_MANUAL"=> \$bisect_manual,
"BISECT_SKIP" => \$bisect_skip,
+"BISECT_TRIES" => \$bisect_tries,
"CONFIG_BISECT_GOOD" => \$config_bisect_good,
"BISECT_RET_GOOD" => \$bisect_ret_good,
"BISECT_RET_BAD" => \$bisect_ret_bad,
@@ -2584,12 +2587,29 @@ sub run_bisect {
$buildtype = "useconfig:$minconfig";
}
-my $ret = run_bisect_test $type, $buildtype;
+# If the user sets bisect_tries to less than 1, then no tries
+# is a success.
+my $ret = 1;
-if ($bisect_manual) {
+# Still let the user manually decide that though.
+if ($bisect_tries < 1 && $bisect_manual) {
$ret = answer_bisect;
}
+for (my $i = 0; $i < $bisect_tries; $i++) {
+ if ($bisect_tries > 1) {
+ my $t = $i + 1;
+ doprint("Running bisect trial $t of $bisect_tries:\n");
+ }
+ $ret = run_bisect_test $type, $buildtype;
+
+ if ($bisect_manual) {
+ $ret = answer_bisect;
+ }
+
+ last if (!$ret);
+}
+
# Are we looking for where it worked, not failed?
if ($reverse_bisect && $ret >= 0) {
$ret = !$ret;
diff --git a/tools/testing/ktest/sample.conf b/tools/testing/ktest/sample.conf
index 2eb4bd2..172eec4 100644
--- a/tools/testing/ktest/sample.conf
+++ b/tools/testing/ktest/sample.conf
@@ -1028,6 +1028,20 @@
# BISECT_BAD with BISECT_CHECK = good or
# BISECT_CHECK = bad, respectively.
#
+# BISECT_TRIES = 5 (optional, default 1)
+#
+# For those cases that it takes several tries to hit a bug,
+# the BISECT_TRIES is useful. It is the number of times the
+# test is ran before it says the kernel is good. The first failure
+# will stop trying and mark the current SHA1 as bad.
+#
+# Note, as with all race bugs, there's no guarantee that if
+# it succeeds, it is really a good bisect. But it helps in case
+# the bug is some what reliable.
+#
+# You can set BISECT_TRIES to zero, and all tests will be considered
+# good, unless you also set BISECT_MANUAL.
+#
# BISECT_RET_GOOD = 0 (optional, default undefined)
#
# In case the specificed test returns something other than just
--
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 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney wrote: > > Yes, this requires that -all- updates to the fields in the machine word > in question use atomic rmw. Which would not be pretty from a core-code > perspective. Hence my suggestion of ceasing Linux-kernel support for > DEC Alpha CPUs that don't support byte operations. Also need 16-bit > operations as well, of course... I'm not seeing this. Why the hell would you have byte- or halfword-sized versions of the store_release or load_acquire things on alpha anyway? What it means is that data structures that do locking or atomics need to be "int" or "long" on alpha. That has always been true. What do you claim has changed? 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: [RFC][PATCH] preempt: Debug for possible missed preemption checks
Hi Steve, On Sat, 18 Jan 2014 18:44:01 -0500 Steven Rostedt wrote: > > On Thu, 16 Jan 2014 21:12:14 -0800 > Andrew Morton wrote: > > > On Thu, 16 Jan 2014 23:57:51 -0500 Steven Rostedt > > wrote: > > > > > When PROVE_LOCKING and PREEMPT is configured, the preempt state > > > tracking is active. Testing this out, I added a module that did the > > > following: > > > > So I assume your kernel at least has no instances of this bug, so we > > don't need the patch ;) It *is* a fairly daft thing to do. > > > > Maybe stick it in -next for a few months, see if anyone hits it? > > Do you have any objections if I add this change to my for-next branch? > I'll do it as a merge as I do not plan on having it go into the next > release. But this is an extension to lockdep that when both > PROVE_LOCKING and PREEMPT are enabled, it can catch a certain bug. But > as Andrew has stated, it did not find any in the kernel that I'm > running. > > What I propose is to have this go into linux-next, as I assume that > people test it with PROVE_LOCKING and PREEMPT enabled, and if someone > adds this bug this patch will catch it (if the bug path is taken). > Hopefully it would be reported and we know two things. One, someone > added a bug, and two, this patch is useful to add to mainline. > > Here's the catch 22, it may not be worth adding to mainline if it never > catches any bugs. But we wont know that unless we add it to mainline. > Maybe adding it to linux-next might be good enough for now. Given that the merge window will probably open today or tomorrow, I would prefer any new code not intended for 3.14 not be added to linux-next until after v3.14-rc1 to avoid unneeded conflicts. If, however, Andrew thinks it is still worth the (maybe minimal) pain, then fine. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBabv0e5B1w.pgp Description: PGP signature
My dear!!!
Hello Dear, How are you dear?. My name is Miss Natasha. I wish to have you as a friend, if you care for my gesture!. Actually, I have an important reasons for asking your interest for a good and serious relationship with us. It will please me, if you can send me a mail. so that, I shall proceed to let to you more about me as well as sending you some of my pictures. Hope to hear from you soon?. Thanks! Natasha -- 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] Adding hyperv.h to uapi headers
Could any of you Hyper-V developers take a look at this, and see if
this split makes sense to you?
Thanks :)
/Bjarke
2014/1/19 Bjarke Istrup Pedersen :
> This patch adds the hyperv.h header to the uapi folder, and adds it to the
> Kbuild file.
> Doing this enables compiling userspace Hyper-V tools using the installed
> headers.
>
> Version 2: Split UAPI parts into new header, instead of duplicating.
>
> Signed-off-by: Bjarke Istrup Pedersen
> ---
> include/linux/hyperv.h | 321 +
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/hyperv.h | 344
>
> 3 files changed, 347 insertions(+), 319 deletions(-)
> create mode 100644 include/uapi/linux/hyperv.h
>
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 15da677..167ef47 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -25,325 +25,9 @@
> #ifndef _HYPERV_H
> #define _HYPERV_H
>
> -#include
> -
> -/*
> - * Framework version for util services.
> - */
> -#define UTIL_FW_MINOR 0
> -
> -#define UTIL_WS2K8_FW_MAJOR 1
> -#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16 | UTIL_FW_MINOR)
> -
> -#define UTIL_FW_MAJOR 3
> -#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 | UTIL_FW_MINOR)
> -
> -
> -/*
> - * Implementation of host controlled snapshot of the guest.
> - */
> -
> -#define VSS_OP_REGISTER 128
> -
> -enum hv_vss_op {
> - VSS_OP_CREATE = 0,
> - VSS_OP_DELETE,
> - VSS_OP_HOT_BACKUP,
> - VSS_OP_GET_DM_INFO,
> - VSS_OP_BU_COMPLETE,
> - /*
> -* Following operations are only supported with IC version >= 5.0
> -*/
> - VSS_OP_FREEZE, /* Freeze the file systems in the VM */
> - VSS_OP_THAW, /* Unfreeze the file systems */
> - VSS_OP_AUTO_RECOVER,
> - VSS_OP_COUNT /* Number of operations, must be last */
> -};
> -
> -
> -/*
> - * Header for all VSS messages.
> - */
> -struct hv_vss_hdr {
> - __u8 operation;
> - __u8 reserved[7];
> -} __attribute__((packed));
> -
> -
> -/*
> - * Flag values for the hv_vss_check_feature. Linux supports only
> - * one value.
> - */
> -#define VSS_HBU_NO_AUTO_RECOVERY 0x0005
> -
> -struct hv_vss_check_feature {
> - __u32 flags;
> -} __attribute__((packed));
> -
> -struct hv_vss_check_dm_info {
> - __u32 flags;
> -} __attribute__((packed));
> -
> -struct hv_vss_msg {
> - union {
> - struct hv_vss_hdr vss_hdr;
> - int error;
> - };
> - union {
> - struct hv_vss_check_feature vss_cf;
> - struct hv_vss_check_dm_info dm_info;
> - };
> -} __attribute__((packed));
> -
> -/*
> - * An implementation of HyperV key value pair (KVP) functionality for Linux.
> - *
> - *
> - * Copyright (C) 2010, Novell, Inc.
> - * Author : K. Y. Srinivasan
> - *
> - */
> -
> -/*
> - * Maximum value size - used for both key names and value data, and includes
> - * any applicable NULL terminators.
> - *
> - * Note: This limit is somewhat arbitrary, but falls easily within what is
> - * supported for all native guests (back to Win 2000) and what is reasonable
> - * for the IC KVP exchange functionality. Note that Windows Me/98/95 are
> - * limited to 255 character key names.
> - *
> - * MSDN recommends not storing data values larger than 2048 bytes in the
> - * registry.
> - *
> - * Note: This value is used in defining the KVP exchange message - this
> value
> - * cannot be modified without affecting the message size and compatibility.
> - */
> -
> -/*
> - * bytes, including any null terminators
> - */
> -#define HV_KVP_EXCHANGE_MAX_VALUE_SIZE (2048)
> -
> -
> -/*
> - * Maximum key size - the registry limit for the length of an entry name
> - * is 256 characters, including the null terminator
> - */
> -
> -#define HV_KVP_EXCHANGE_MAX_KEY_SIZE(512)
> +#include
>
> -/*
> - * In Linux, we implement the KVP functionality in two components:
> - * 1) The kernel component which is packaged as part of the hv_utils driver
> - * is responsible for communicating with the host and responsible for
> - * implementing the host/guest protocol. 2) A user level daemon that is
> - * responsible for data gathering.
> - *
> - * Host/Guest Protocol: The host iterates over an index and expects the guest
> - * to assign a key name to the index and also return the value corresponding
> to
> - * the key. The host will have atmost one KVP transaction outstanding at any
> - * given point in time. The host side iteration stops when the guest returns
> - * an error. Microsoft has specified the following mapping of key names to
> - * host specified index:
> - *
> - * Index Key Name
> - * 0 FullyQualifiedDomainName
> - * 1 IntegrationServicesVersion
> - * 2 NetworkAddressIPv4
> - * 3 NetworkAddressIPv6
> - * 4
Re: [PATCH] Adding hyperv.h to uapi headers
2014/1/19 Borislav Petkov : > On Sun, Jan 19, 2014 at 12:24:10AM +0100, Bjarke Istrup Pedersen wrote: >> I have submitted a v2 patch - does it look better? > > If you mean this: > > include/linux/hyperv.h | 321 + > include/uapi/linux/Kbuild | 1 + > include/uapi/linux/hyperv.h | 344 > > 3 files changed, 347 insertions(+), 319 deletions(-) > create mode 100644 include/uapi/linux/hyperv.h > > you've got the rough idea of uapi headers :-). Yep, that one, thanks :-) > Whether that makes sense at all in the hyperv case, you'll have to wait > for the hyperv guys to say something. > > What makes me wonder is why do you need to export this now? To be able to build the kvp deamon, which has been broken since the UAPI split a few versions ago. > Because if those userspace hyperv tools would really need the > definitions in that header, then they never did build before. Which > would be really stupid. Btw, which userspace hyperv tools do you mean? > Where are they? The tool located in tools/hv. For some reason, this was never fixed, but now my machines started complaining in dmesg that the kvp deamon should be updated, so I took a look at it. /Bjarke > What am I missing? > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- > 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/ -- 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 PATCHv2 2/2] Change khugepaged to respect MMF_THP_DISABLE flag
On Thu, Jan 16, 2014 at 03:01:44PM -0600, Alex Thorlton wrote:
> This just adds a simple check to get khugepaged to behave
> appropriately when MMF_THP_DISABLE is set.
>
> Signed-off-by: Alex Thorlton
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Andrew Morton
> Cc: "Kirill A. Shutemov"
> Cc: Benjamin Herrenschmidt
> Cc: Rik van Riel
> Cc: Naoya Horiguchi
> Cc: Oleg Nesterov
> Cc: "Eric W. Biederman"
> Cc: Andy Lutomirski
> Cc: Al Viro
> Cc: Kees Cook
> Cc: Andrea Arcangeli
> Cc: linux-kernel@vger.kernel.org
>
> ---
> mm/huge_memory.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9c0b172..3cfe6b4 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2049,7 +2049,8 @@ static void insert_to_mm_slots_hash(struct mm_struct
> *mm,
>
> static inline int khugepaged_test_exit(struct mm_struct *mm)
> {
> - return atomic_read(>mm_users) == 0;
> + return atomic_read(>mm_users) == 0 ||
> +(mm->flags & MMF_THP_DISABLE_MASK);
__khugepaged_enter() has VM_BUG_ON(khugepaged_test_exit(mm)).
Do we really want to crash there if MMF_THP_DISABLE is set?
--
Kirill A. Shutemov
--
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 PATCHv2 1/2] Add mm flag to control THP
On Thu, Jan 16, 2014 at 03:01:43PM -0600, Alex Thorlton wrote:
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 91672e2..475f59f 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -1,6 +1,8 @@
> #ifndef _LINUX_HUGE_MM_H
> #define _LINUX_HUGE_MM_H
>
> +#include
> +
Hm, now depends on . It doesn't look as a good
idea.
Why do we have MMF_* defines in ?
Wouldn't it more appropriate to put them in ?
> extern int do_huge_pmd_anonymous_page(struct mm_struct *mm,
> struct vm_area_struct *vma,
> unsigned long address, pmd_t *pmd,
> @@ -74,7 +76,8 @@ extern bool is_vma_temporary_stack(struct vm_area_struct
> *vma);
> (1< ((__vma)->vm_flags & VM_HUGEPAGE))) && \
>!((__vma)->vm_flags & VM_NOHUGEPAGE) &&\
> - !is_vma_temporary_stack(__vma))
> + !is_vma_temporary_stack(__vma) && \
> + !test_bit(MMF_THP_DISABLE, &(__vma)->vm_mm->flags))
> #define transparent_hugepage_defrag(__vma) \
> ((transparent_hugepage_flags & \
> (1< @@ -227,7 +230,6 @@ static inline int do_huge_pmd_numa_page(struct mm_struct
> *mm, struct vm_area_str
> {
> return 0;
> }
> -
> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>
> #endif /* _LINUX_HUGE_MM_H */
Why?
--
Kirill A. Shutemov
--
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] Adding hyperv.h to uapi headers
On Sun, Jan 19, 2014 at 12:24:10AM +0100, Bjarke Istrup Pedersen wrote: > I have submitted a v2 patch - does it look better? If you mean this: include/linux/hyperv.h | 321 + include/uapi/linux/Kbuild | 1 + include/uapi/linux/hyperv.h | 344 3 files changed, 347 insertions(+), 319 deletions(-) create mode 100644 include/uapi/linux/hyperv.h you've got the rough idea of uapi headers :-). Whether that makes sense at all in the hyperv case, you'll have to wait for the hyperv guys to say something. What makes me wonder is why do you need to export this now? Because if those userspace hyperv tools would really need the definitions in that header, then they never did build before. Which would be really stupid. Btw, which userspace hyperv tools do you mean? Where are they? What am I missing? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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][PATCH] preempt: Debug for possible missed preemption checks
On Thu, 16 Jan 2014 21:12:14 -0800 Andrew Morton wrote: > On Thu, 16 Jan 2014 23:57:51 -0500 Steven Rostedt wrote: > > > When PROVE_LOCKING and PREEMPT is configured, the preempt state > > tracking is active. Testing this out, I added a module that did the > > following: > > So I assume your kernel at least has no instances of this bug, so we > don't need the patch ;) It *is* a fairly daft thing to do. > > Maybe stick it in -next for a few months, see if anyone hits it? Stephen, Do you have any objections if I add this change to my for-next branch? I'll do it as a merge as I do not plan on having it go into the next release. But this is an extension to lockdep that when both PROVE_LOCKING and PREEMPT are enabled, it can catch a certain bug. But as Andrew has stated, it did not find any in the kernel that I'm running. What I propose is to have this go into linux-next, as I assume that people test it with PROVE_LOCKING and PREEMPT enabled, and if someone adds this bug this patch will catch it (if the bug path is taken). Hopefully it would be reported and we know two things. One, someone added a bug, and two, this patch is useful to add to mainline. Here's the catch 22, it may not be worth adding to mainline if it never catches any bugs. But we wont know that unless we add it to mainline. Maybe adding it to linux-next might be good enough for now. -- 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/
[PATCH net-next v3 3/3] reciprocal_divide: update/correction of the algorithm
From: Hannes Frederic Sowa
Jakub Zawadzki noticed that some divisions by reciprocal_divide()
were not correct [1][2], which he could also show with BPF code
after divisions are transformed into reciprocal_value() for runtime
invariance which can be passed to reciprocal_divide() later on;
reverse in BPF dump ended up with a different, off-by-one K in
some situations.
This has been fixed by Eric Dumazet in commit aee636c4809fa5
("bpf: do not use reciprocal divide"). This follow-up patch
improves reciprocal_value() and reciprocal_divide() to work in
all cases by using Granlund and Montgomery method, so that also
future use is safe and without any non-obvious side-effects.
Known problems with the old implementation were that division by 1
always returned 0 and some off-by-ones when the dividend and divisor
where very large. This seemed to not be problematic with its
current users, as far as we can tell. Eric Dumazet checked for
the slab usage, we cannot surely say so in the case of flex_array.
Still, in order to fix that, we propose an extension from the
original implementation from commit 6a2d7a955d8d resp. [3][4],
by using the algorithm proposed in "Division by Invariant Integers
Using Multiplication" [5], Torbjörn Granlund and Peter L.
Montgomery, that is, pseudocode for q = n/d where q, n, d is in
u32 universe:
1) Initialization:
int l = ceil(log_2 d)
uword m' = floor((1<<32)*((1<>32
q = (t+((n-t)>>sh_1))>>sh_2
The assembler implementation from Agner Fog [6] also helped a lot
while implementing. We have tested the implementation on x86_64,
ppc64, i686, s390x; on x86_64/haswell we're still half the latency
compared to normal divide.
Joint work with Daniel Borkmann.
[1] http://www.wireshark.org/~darkjames/reciprocal-buggy.c
[2] http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c
[3] https://gmplib.org/~tege/division-paper.pdf
[4] http://homepage.cs.uiowa.edu/~jones/bcd/divide.html
[5] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.2556
[6] http://www.agner.org/optimize/asmlib.zip
Reported-by: Jakub Zawadzki
Cc: Eric Dumazet
Cc: Austin S Hemmelgarn
Cc: linux-kernel@vger.kernel.org
Cc: Jesse Gross
Cc: Jamal Hadi Salim
Cc: Stephen Hemminger
Cc: Matt Mackall
Cc: Pekka Enberg
Cc: Christoph Lameter
Cc: Andy Gospodarek
Cc: Veaceslav Falico
Cc: Jay Vosburgh
Cc: Jakub Zawadzki
Signed-off-by: Daniel Borkmann
Signed-off-by: Hannes Frederic Sowa
---
drivers/net/bonding/bond_main.c| 24 ---
drivers/net/bonding/bond_netlink.c | 4
drivers/net/bonding/bond_options.c | 15 ++-
drivers/net/bonding/bond_sysfs.c | 5 -
drivers/net/bonding/bonding.h | 3 +++
include/linux/flex_array.h | 3 ++-
include/linux/reciprocal_div.h | 39 --
include/linux/slab_def.h | 4 +++-
include/net/red.h | 3 ++-
lib/flex_array.c | 7 ++-
lib/reciprocal_div.c | 24 +++
net/sched/sch_netem.c | 6 --
12 files changed, 88 insertions(+), 49 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 3220b48..f100bd9 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -79,7 +79,6 @@
#include
#include
#include
-#include
#include "bonding.h"
#include "bond_3ad.h"
#include "bond_alb.h"
@@ -3596,8 +3595,9 @@ static void bond_xmit_slave_id(struct bonding *bond,
struct sk_buff *skb, int sl
*/
static u32 bond_rr_gen_slave_id(struct bonding *bond)
{
- int packets_per_slave = bond->params.packets_per_slave;
u32 slave_id;
+ struct reciprocal_value reciprocal_packets_per_slave;
+ int packets_per_slave = bond->params.packets_per_slave;
switch (packets_per_slave) {
case 0:
@@ -3607,8 +3607,10 @@ static u32 bond_rr_gen_slave_id(struct bonding *bond)
slave_id = bond->rr_tx_counter;
break;
default:
+ reciprocal_packets_per_slave =
+ bond->params.reciprocal_packets_per_slave;
slave_id = reciprocal_divide(bond->rr_tx_counter,
-packets_per_slave);
+reciprocal_packets_per_slave);
break;
}
bond->rr_tx_counter++;
@@ -4343,10 +4345,18 @@ static int bond_check_params(struct bond_params *params)
params->resend_igmp = resend_igmp;
params->min_links = min_links;
params->lp_interval = lp_interval;
- if (packets_per_slave > 1)
- params->packets_per_slave = reciprocal_value(packets_per_slave);
- else
- params->packets_per_slave = packets_per_slave;
+ params->packets_per_slave = packets_per_slave;
+ if (packets_per_slave > 0) {
+ params->reciprocal_packets_per_slave =
+
[PATCH net-next v3 1/3] random32: add prandom_u32_max and convert open coded users
Many functions have open coded a function that returns a random
number in range [0,N-1]. Under the assumption that we have a PRNG
such as taus113 with being well distributed in [0, ~0U] space,
we can implement such a function as uword t = (n*m')>>32, where
m' is a random number obtained from PRNG, n the right open interval
border and t our resulting random number, with n,m',t in u32 universe.
Lets go with Joe and simply call it prandom_u32_max(), although
technically we have an right open interval endpoint, but that we
have documented. Other users can further be migrated to the new
prandom_u32_max() function later on; for now, we need to make sure
to migrate reciprocal_divide() users for the reciprocal_divide()
follow-up fixup since their function signatures are going to change.
Joint work with Hannes Frederic Sowa.
Cc: Jakub Zawadzki
Cc: Eric Dumazet
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: Daniel Borkmann
---
drivers/net/team/team_mode_random.c | 8 +---
include/linux/random.h | 18 +-
net/packet/af_packet.c | 2 +-
net/sched/sch_choke.c | 9 +
4 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/net/team/team_mode_random.c
b/drivers/net/team/team_mode_random.c
index 7f032e2..cd2f692 100644
--- a/drivers/net/team/team_mode_random.c
+++ b/drivers/net/team/team_mode_random.c
@@ -13,20 +13,14 @@
#include
#include
#include
-#include
#include
-static u32 random_N(unsigned int N)
-{
- return reciprocal_divide(prandom_u32(), N);
-}
-
static bool rnd_transmit(struct team *team, struct sk_buff *skb)
{
struct team_port *port;
int port_index;
- port_index = random_N(team->en_port_count);
+ port_index = prandom_u32_max(team->en_port_count);
port = team_get_port_by_index_rcu(team, port_index);
if (unlikely(!port))
goto drop;
diff --git a/include/linux/random.h b/include/linux/random.h
index 4002b3d..3e89ac9 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -8,7 +8,6 @@
#include
-
extern void add_device_randomness(const void *, unsigned int);
extern void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value);
@@ -38,6 +37,23 @@ struct rnd_state {
u32 prandom_u32_state(struct rnd_state *state);
void prandom_bytes_state(struct rnd_state *state, void *buf, int nbytes);
+/**
+ * prandom_u32_max - returns a pseduo-random number in interval [0, ep_ro)
+ * @ep_ro: right open interval endpoint
+ *
+ * Returns a pseduo-random number that is in interval [0, ep_ro). Note
+ * that the result depends on PRNG being well distributed in [0, ~0U]
+ * u32 space. Here we use maximally equidistributed combined Tausworthe
+ * generator, that is, prandom_u32(). This is useful when requesting a
+ * random index of an array containing ep_ro elements, for example.
+ *
+ * Returns: pseduo-random number in interval [0, ep_ro)
+ */
+static inline u32 prandom_u32_max(u32 ep_ro)
+{
+ return (u32)(((u64) prandom_u32() * ep_ro) >> 32);
+}
+
/*
* Handle minimum values for seeds
*/
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 12f2f72..266c311 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1289,7 +1289,7 @@ static unsigned int fanout_demux_rnd(struct packet_fanout
*f,
struct sk_buff *skb,
unsigned int num)
{
- return reciprocal_divide(prandom_u32(), num);
+ return prandom_u32_max(num);
}
static unsigned int fanout_demux_rollover(struct packet_fanout *f,
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index ddd73cb..2aee028 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -77,12 +76,6 @@ struct choke_sched_data {
struct sk_buff **tab;
};
-/* deliver a random number between 0 and N - 1 */
-static u32 random_N(unsigned int N)
-{
- return reciprocal_divide(prandom_u32(), N);
-}
-
/* number of elements in queue including holes */
static unsigned int choke_len(const struct choke_sched_data *q)
{
@@ -233,7 +226,7 @@ static struct sk_buff *choke_peek_random(const struct
choke_sched_data *q,
int retrys = 3;
do {
- *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+ *pidx = (q->head + prandom_u32_max(choke_len(q))) & q->tab_mask;
skb = q->tab[*pidx];
if (skb)
return skb;
--
1.8.3.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 net-next v3 2/3] net: introduce reciprocal_scale helper and convert users
As David Laight suggests, we shouldn't necessarily call this
reciprocal_divide() when users didn't requested a reciprocal_value();
lets keep the basic idea and call it reciprocal_scale(). More
background information on this topic can be found in [1].
Joint work with Hannes Frederic Sowa.
[1] http://homepage.cs.uiowa.edu/~jones/bcd/divide.html
Suggested-by: David Laight
Cc: Jakub Zawadzki
Cc: Eric Dumazet
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: Daniel Borkmann
---
include/linux/kernel.h | 19 +++
include/net/codel.h| 4 +---
net/packet/af_packet.c | 3 +--
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index ecb8754..7afdbd2 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -193,6 +193,25 @@ extern int _cond_resched(void);
(__x < 0) ? -__x : __x; \
})
+/**
+ * reciprocal_scale - "scale" a value into range [0, ep_ro)
+ * @val: value
+ * @ep_ro: right open interval endpoint
+ *
+ * Perform a "reciprocal multiplication" in order to "scale" a value into
+ * range [0, ep_ro), where the upper interval endpoint is right-open.
+ * This is useful, e.g. for accessing a index of an array containing
+ * ep_ro elements, for example. Think of it as sort of modulus, only that
+ * the result isn't that of modulo. ;) Note that if initial input is a
+ * small value, then result will return 0.
+ *
+ * Return: a result based on val in interval [0, ep_ro).
+ */
+static inline u32 reciprocal_scale(u32 val, u32 ep_ro)
+{
+ return (u32)(((u64) val * ep_ro) >> 32);
+}
+
#if defined(CONFIG_MMU) && \
(defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP))
void might_fault(void);
diff --git a/include/net/codel.h b/include/net/codel.h
index 3b04ff5..fe0eab3 100644
--- a/include/net/codel.h
+++ b/include/net/codel.h
@@ -46,7 +46,6 @@
#include
#include
#include
-#include
/* Controlling Queue Delay (CoDel) algorithm
* =
@@ -211,10 +210,9 @@ static codel_time_t codel_control_law(codel_time_t t,
codel_time_t interval,
u32 rec_inv_sqrt)
{
- return t + reciprocal_divide(interval, rec_inv_sqrt <<
REC_INV_SQRT_SHIFT);
+ return t + reciprocal_scale(interval, rec_inv_sqrt <<
REC_INV_SQRT_SHIFT);
}
-
static bool codel_should_drop(const struct sk_buff *skb,
struct Qdisc *sch,
struct codel_vars *vars,
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 266c311..141b019 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -88,7 +88,6 @@
#include
#include
#include
-#include
#include
#ifdef CONFIG_INET
#include
@@ -1262,7 +1261,7 @@ static unsigned int fanout_demux_hash(struct
packet_fanout *f,
struct sk_buff *skb,
unsigned int num)
{
- return reciprocal_divide(skb->rxhash, num);
+ return reciprocal_scale(skb->rxhash, num);
}
static unsigned int fanout_demux_lb(struct packet_fanout *f,
--
1.8.3.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] USB: input: gtco.c: fix usb_dev leak
There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
anywhere in the driver.
The patch adds usb_get_dev() to failure handling code of gtco_probe()
and to gtco_disconnect(().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/input/tablet/gtco.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 29e01ab6859f..6ec8a3a04672 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -858,7 +858,7 @@ static int gtco_probe(struct usb_interface *usbinterface,
if (!gtco->buffer) {
dev_err(>dev, "No more memory for us buffers\n");
error = -ENOMEM;
- goto err_free_devs;
+ goto err_put_usb;
}
/* Allocate URB for reports */
@@ -990,6 +990,8 @@ static int gtco_probe(struct usb_interface *usbinterface,
err_free_buf:
usb_free_coherent(gtco->usbdev, REPORT_MAX_SIZE,
gtco->buffer, gtco->buf_dma);
+ err_put_usb:
+ usb_put_dev(gtco->usbdev);
err_free_devs:
input_free_device(input_dev);
kfree(gtco);
@@ -1013,6 +1015,7 @@ static void gtco_disconnect(struct usb_interface
*interface)
usb_free_urb(gtco->urbinfo);
usb_free_coherent(gtco->usbdev, REPORT_MAX_SIZE,
gtco->buffer, gtco->buf_dma);
+ usb_put_dev(gtco->usbdev);
kfree(gtco);
}
--
1.8.3.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] Adding hyperv.h to uapi headers
2014/1/18 Borislav Petkov : > On Sat, Jan 18, 2014 at 11:24:53PM +0100, Bjarke Istrup Pedersen wrote: >> I should take all the parts the is not guarded by __KERNEL__, and move >> them to a uapi header, and then include it at the top of the normal >> header. Correct understood? :) > > Yes, that's basically the approach but be conservative - export only > stuff which *really* is needed by userspace. And hyperv people should > sanity-check what you're exporting because once it is out, it is cast in > stone and there's no changing. I have submitted a v2 patch - does it look better? Thanks :) /Bjarke > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- > 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/ -- 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] Adding hyperv.h to uapi headers
This patch adds the hyperv.h header to the uapi folder, and adds it to the
Kbuild file.
Doing this enables compiling userspace Hyper-V tools using the installed
headers.
Version 2: Split UAPI parts into new header, instead of duplicating.
Signed-off-by: Bjarke Istrup Pedersen
---
include/linux/hyperv.h | 321 +
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/hyperv.h | 344
3 files changed, 347 insertions(+), 319 deletions(-)
create mode 100644 include/uapi/linux/hyperv.h
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 15da677..167ef47 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -25,325 +25,9 @@
#ifndef _HYPERV_H
#define _HYPERV_H
-#include
-
-/*
- * Framework version for util services.
- */
-#define UTIL_FW_MINOR 0
-
-#define UTIL_WS2K8_FW_MAJOR 1
-#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16 | UTIL_FW_MINOR)
-
-#define UTIL_FW_MAJOR 3
-#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 | UTIL_FW_MINOR)
-
-
-/*
- * Implementation of host controlled snapshot of the guest.
- */
-
-#define VSS_OP_REGISTER 128
-
-enum hv_vss_op {
- VSS_OP_CREATE = 0,
- VSS_OP_DELETE,
- VSS_OP_HOT_BACKUP,
- VSS_OP_GET_DM_INFO,
- VSS_OP_BU_COMPLETE,
- /*
-* Following operations are only supported with IC version >= 5.0
-*/
- VSS_OP_FREEZE, /* Freeze the file systems in the VM */
- VSS_OP_THAW, /* Unfreeze the file systems */
- VSS_OP_AUTO_RECOVER,
- VSS_OP_COUNT /* Number of operations, must be last */
-};
-
-
-/*
- * Header for all VSS messages.
- */
-struct hv_vss_hdr {
- __u8 operation;
- __u8 reserved[7];
-} __attribute__((packed));
-
-
-/*
- * Flag values for the hv_vss_check_feature. Linux supports only
- * one value.
- */
-#define VSS_HBU_NO_AUTO_RECOVERY 0x0005
-
-struct hv_vss_check_feature {
- __u32 flags;
-} __attribute__((packed));
-
-struct hv_vss_check_dm_info {
- __u32 flags;
-} __attribute__((packed));
-
-struct hv_vss_msg {
- union {
- struct hv_vss_hdr vss_hdr;
- int error;
- };
- union {
- struct hv_vss_check_feature vss_cf;
- struct hv_vss_check_dm_info dm_info;
- };
-} __attribute__((packed));
-
-/*
- * An implementation of HyperV key value pair (KVP) functionality for Linux.
- *
- *
- * Copyright (C) 2010, Novell, Inc.
- * Author : K. Y. Srinivasan
- *
- */
-
-/*
- * Maximum value size - used for both key names and value data, and includes
- * any applicable NULL terminators.
- *
- * Note: This limit is somewhat arbitrary, but falls easily within what is
- * supported for all native guests (back to Win 2000) and what is reasonable
- * for the IC KVP exchange functionality. Note that Windows Me/98/95 are
- * limited to 255 character key names.
- *
- * MSDN recommends not storing data values larger than 2048 bytes in the
- * registry.
- *
- * Note: This value is used in defining the KVP exchange message - this value
- * cannot be modified without affecting the message size and compatibility.
- */
-
-/*
- * bytes, including any null terminators
- */
-#define HV_KVP_EXCHANGE_MAX_VALUE_SIZE (2048)
-
-
-/*
- * Maximum key size - the registry limit for the length of an entry name
- * is 256 characters, including the null terminator
- */
-
-#define HV_KVP_EXCHANGE_MAX_KEY_SIZE(512)
+#include
-/*
- * In Linux, we implement the KVP functionality in two components:
- * 1) The kernel component which is packaged as part of the hv_utils driver
- * is responsible for communicating with the host and responsible for
- * implementing the host/guest protocol. 2) A user level daemon that is
- * responsible for data gathering.
- *
- * Host/Guest Protocol: The host iterates over an index and expects the guest
- * to assign a key name to the index and also return the value corresponding to
- * the key. The host will have atmost one KVP transaction outstanding at any
- * given point in time. The host side iteration stops when the guest returns
- * an error. Microsoft has specified the following mapping of key names to
- * host specified index:
- *
- * Index Key Name
- * 0 FullyQualifiedDomainName
- * 1 IntegrationServicesVersion
- * 2 NetworkAddressIPv4
- * 3 NetworkAddressIPv6
- * 4 OSBuildNumber
- * 5 OSName
- * 6 OSMajorVersion
- * 7 OSMinorVersion
- * 8 OSVersion
- * 9 ProcessorArchitecture
- *
- * The Windows host expects the Key Name and Key Value to be encoded in utf16.
- *
- * Guest Kernel/KVP Daemon Protocol: As noted earlier, we implement all of the
- * data gathering functionality in a user mode daemon. The user level daemon
- * is also
Re: [PATCH] Adding hyperv.h to uapi headers
2014/1/18 Borislav Petkov : > On Sat, Jan 18, 2014 at 11:24:53PM +0100, Bjarke Istrup Pedersen wrote: >> I should take all the parts the is not guarded by __KERNEL__, and move >> them to a uapi header, and then include it at the top of the normal >> header. Correct understood? :) > > Yes, that's basically the approach but be conservative - export only > stuff which *really* is needed by userspace. And hyperv people should > sanity-check what you're exporting because once it is out, it is cast in > stone and there's no changing. > Okay - I'll take a look at it, and post a v2 patch in a moment. >From what I can see, it looks like the userspace parts are all logical to have exported (quite a few of them are using by the kvp tool, and the rest makes sense AFAICS). /Bjarke > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- > 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/ -- 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: 3.12.8 poor network performance x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi again, Am 18.01.2014 20:50, schrieb Borislav Petkov: > + netdev. Thx Am 18.01.2014 20:49, schrieb Holger Hoffstätte:> [This mail was also posted to gmane.linux.kernel.] > > On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote: > >> I recently upgraded the Kernel from version 3.10 to latest >> stable 3.12.8, did the usual "make oldconfig" (resulting config >> attached). >> >> But now I noticed some _really_ low network performance. > > Try: sysctl net.ipv4.tcp_limit_output_bytes=262144 Tried that. Even 10 times the value. Same effect. Is there something like that on a lower level of the network stack I might try to change? Could that be something in the cgroups layer? Should I send a dmesg or anything else? Greetings Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS2wQtAAoJEPI6v6bI/QkfKakP/jsv7VG5bUuSbvXjLQklb8mY kGZvXRktpGMxHbUJe8NCLStbWcGLRoD+ilXh38e0U+icgU/f6uAa6a93cSaF+zi8 imjkyutQqAlevV3Ab3SAaSho6SsWgfTkWZ7kkFooIXU6UwIlqq41923OTpR2bXL4 qvYiYEOOO9Uzg/o0PXeV2VYcgxfnvTqRrpou3yQZK5YhLAZIHd8i9r1yqc+Un4dG 7+Ju/45YpqynX2CJVMx5kP62f9uQbdA9sEKoEkYInVtja0UGUwFXzHgy8RZLHDiM Qhy/yZTzkjR4vai4N+dx2UizGBwgBtng5IzUiXX2HGd8TOMJRBcoPaa0ZBA4CsA+ RjypqL9dOGpw1bxZ/87h9qpvjmZd3mPhb768VKXgzgdEVlp56u5rT1OQEBUju8aS Qprgtf6k1EkjJPWo3DVJrGr/Wk+k8cLASW5qm3wGS7V0k1H0EN+pw7UGvNY99kcf IllTKa6bTkKe15x1BaZjvAwFHR1Fdcdn3A+2WQwy+hha1CsjogHnbhzUjmxHDq+c 8i92oZ1nw2788/ULPKc5hK2o8C4Zsp0JVGHd4Cy4Dy6tvCLSQveDneM/2U3JvCL2 ViOdxh6LGGWFvDpe1w9x+e3QzvXYTFNEXawn/5OIEzbM1XP+VF8zIyHsLG4nNI88 +ICSvsTt86Zg8Zhm96YH =gsnO -END PGP SIGNATURE- -- 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] Adding hyperv.h to uapi headers
On Sat, Jan 18, 2014 at 11:24:53PM +0100, Bjarke Istrup Pedersen wrote: > I should take all the parts the is not guarded by __KERNEL__, and move > them to a uapi header, and then include it at the top of the normal > header. Correct understood? :) Yes, that's basically the approach but be conservative - export only stuff which *really* is needed by userspace. And hyperv people should sanity-check what you're exporting because once it is out, it is cast in stone and there's no changing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] Adding hyperv.h to uapi headers
2014/1/18 Borislav Petkov : > On Sat, Jan 18, 2014 at 11:07:10PM +0100, Bjarke Istrup Pedersen wrote: >> I have been thinking about other solutions, but so far, I haven't been >> able to find one that solves it, so the tools build. (An option might >> be to strip it from the __KERNEL__ part, to make it smaller, but I >> don't know what difference that would make :-) > > The fix is to move the userspace stuff into the uapi header and include > that header in the kernel header. > > See include/linux/sched.h and many others for an example. > Okay, so let me see if I get this right. I should take all the parts the is not guarded by __KERNEL__, and move them to a uapi header, and then include it at the top of the normal header. Correct understood? :) /Bjarke > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- 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/
[ANNOUNCE] 3.4.77-rt95
Dear RT Folks, I'm pleased to announce the 3.4.77-rt95 stable release. This release is just an update to the new stable 3.4.77 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: d0e3791e29a3155726b7bace5115a3e7e5596f94 Or to build 3.4.77-rt95 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.77.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.77-rt95.patch.xz Enjoy, -- 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/
[ANNOUNCE] 3.2.54-rt77
Dear RT Folks, I'm pleased to announce the 3.2.54-rt77 stable release. This release is just an update to the new stable 3.2.54 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.2-rt Head SHA1: f1fcf5146f16cce6268b096579affe33364a9135 Or to build 3.2.54-rt77 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.54.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.54-rt77.patch.xz Enjoy, -- 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/
[ANNOUNCE] 3.10.27-rt25
Dear RT Folks, I'm pleased to announce the 3.10.27-rt25 stable release. This release is just an update to the new stable 3.10.27 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: 57d2f2e8024d2a07272a24dcc4f8e3230f08e73b Or to build 3.10.27-rt25 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.27.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.27-rt25.patch.xz Enjoy, -- 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: Help Needed
On 01/18/2014 09:34 AM, Madhusudhan Rao Sripalle wrote: > Hi, > > I am an expert of HP-UX (kernel and drivers), while being novice at > linux. I am currently looking ways for quick ramp up so that I could > contribute to linux community. > > Kindly provide pointers starting from where I could get the kernel > sources. Appreciate help in advance. google for "linux kernel source" -- the top 2 URLs give you the kernel source trees ... unless you want the source for some particular distro like Red Hat, SuSE, Ubuntu, ArchLinux, etc., then you would need to go to the web sites of those distros to find the sources. Also check http://kernelnewbies.org/ for some newbie info. -- ~Randy -- 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] Adding hyperv.h to uapi headers
On Sat, Jan 18, 2014 at 11:07:10PM +0100, Bjarke Istrup Pedersen wrote: > I have been thinking about other solutions, but so far, I haven't been > able to find one that solves it, so the tools build. (An option might > be to strip it from the __KERNEL__ part, to make it smaller, but I > don't know what difference that would make :-) The fix is to move the userspace stuff into the uapi header and include that header in the kernel header. See include/linux/sched.h and many others for an example. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] Adding hyperv.h to uapi headers
2014/1/18 Paul Bolle > > Bjarke Istrup Pedersen schreef op za 18-01-2014 om 20:48 [+]: > > This patch adds the hyperv.h header to the uapi folder, and adds it to the > > Kbuild file. > > Doing this enables compiling userspace Hyper-V tools using the installed > > headers. > > > > Signed-off-by: Bjarke Istrup Pedersen > > --- > > include/uapi/linux/Kbuild |1 + > > include/uapi/linux/hyperv.h | 1469 > > +++ > > 2 files changed, 1470 insertions(+) > > create mode 100644 include/uapi/linux/hyperv.h > > Now we have two identical files: include/linux/hyperv.h and > include/uapi/linux/hyperv.h. That seems sub-optimal at best. > (Resending, since gmail seems to default to html mails...) I agree, but it fixes the problem. I have been thinking about other solutions, but so far, I haven't been able to find one that solves it, so the tools build. (An option might be to strip it from the __KERNEL__ part, to make it smaller, but I don't know what difference that would make :-) /Bjarke > > Paul Bolle > > -- > 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/ -- 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 0/7] pseudo-interleaving for automatic NUMA balancing
On 1/17/2014 1:12 PM, r...@redhat.com wrote: The current automatic NUMA balancing code base has issues with workloads that do not fit on one NUMA load. Page migration is slowed down, but memory distribution between the nodes where the workload runs is essentially random, often resulting in a suboptimal amount of memory bandwidth being available to the workload. In order to maximize performance of workloads that do not fit in one NUMA node, we want to satisfy the following criteria: 1) keep private memory local to each thread 2) avoid excessive NUMA migration of pages 3) distribute shared memory across the active nodes, to maximize memory bandwidth available to the workload This patch series identifies the NUMA nodes on which the workload is actively running, and balances (somewhat lazily) the memory between those nodes, satisfying the criteria above. As usual, the series has had some performance testing, but it could always benefit from more testing, on other systems. Changes since v1: - fix divide by zero found by Chegu Vinod - improve comment, as suggested by Peter Zijlstra - do stats calculations in task_numa_placement in local variables Some performance numbers, with two 40-warehouse specjbb instances on an 8 node system with 10 CPU cores per node, using a pre-cleanup version of these patches, courtesy of Chegu Vinod: numactl manual pinning spec1.txt: throughput = 755900.20 SPECjbb2005 bops spec2.txt: throughput = 754914.40 SPECjbb2005 bops NO-pinning results (Automatic NUMA balancing, with patches) spec1.txt: throughput = 706439.84 SPECjbb2005 bops spec2.txt: throughput = 729347.75 SPECjbb2005 bops NO-pinning results (Automatic NUMA balancing, without patches) spec1.txt: throughput = 667988.47 SPECjbb2005 bops spec2.txt: throughput = 638220.45 SPECjbb2005 bops No Automatic NUMA and NO-pinning results spec1.txt: throughput = 544120.97 SPECjbb2005 bops spec2.txt: throughput = 453553.41 SPECjbb2005 bops My own performance numbers are not as relevant, since I have been running with a more hostile workload on purpose, and I have run into a scheduler issue that caused the workload to run on only two of the four NUMA nodes on my test system... . Acked-by: Chegu Vinod Here are some results using the v2 version of the patches on an 8 socket box using SPECjbb2005 as a workload : I) Eight 1-socket wide instances(10 warehouse threads each) : Without patchesWith patches a) numactl pinning results spec1.txt: throughput = 270620.04 273675.10 spec2.txt: throughput = 274115.33 272845.17 spec3.txt: throughput = 277830.09 272057.33 spec4.txt: throughput = 270898.52 270670.54 spec5.txt: throughput = 270397.30 270906.82 spec6.txt: throughput = 270451.93 268217.55 spec7.txt: throughput = 269511.07 269354.46 spec8.txt: throughput = 269386.06 270540.00 b)Automatic NUMA balancing results spec1.txt: throughput = 244333.41 248072.72 spec2.txt: throughput = 252166.99 251818.30 spec3.txt: throughput = 251365.58 258266.24 spec4.txt: throughput = 245247.91 256873.51 spec5.txt: throughput = 245579.68 247743.18 spec6.txt: throughput = 249767.38 256285.86 spec7.txt: throughput = 244570.64 255343.99 spec8.txt: throughput = 245703.60 254434.36 c)NO Automatic NUMA balancing and NO-pinning results spec1.txt: throughput = 132959.73 136957.12 spec2.txt: throughput = 127937.11 129326.23 spec3.txt: throughput = 130697.10 125772.11 spec4.txt: throughput = 134978.49 141607.58 spec5.txt: throughput = 127574.34 126748.18 spec6.txt: throughput = 138699.99 128597.95 spec7.txt: throughput = 133247.25 137344.57 spec8.txt: throughput = 124548.00 139040.98 -- II) Four 2-socket wide instances(20 warehouse threads each) : Without patchesWith patches a) numactl pinning results spec1.txt: throughput = 479931.16 472467.58 spec2.txt: throughput = 466652.15 466237.10 spec3.txt: throughput =
[PATCH] iio: gyro: itg3200: Add DT support.
Signed-off-by: NeilBrown
Signed-off-by: Marek Belisko
---
V2:
Added entries to i2c/trivial-devices and also add invensense to vendor-prefixes
file.
.../devicetree/bindings/i2c/trivial-devices.txt| 1 +
.../devicetree/bindings/iio/gyro/itg3200.txt | 22 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/iio/gyro/itg3200_core.c| 9 +
4 files changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/gyro/itg3200.txt
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 1a1ac2e..86078de 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -40,6 +40,7 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog
with Two-Wire Interface
infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max
100khz)
infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
+invensense,itg3200 InvenSense ITG-3200, Gyroscope
isl,isl12057 Intersil ISL12057 I2C RTC Chip
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
diff --git a/Documentation/devicetree/bindings/iio/gyro/itg3200.txt
b/Documentation/devicetree/bindings/iio/gyro/itg3200.txt
new file mode 100644
index 000..b1b18dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/gyro/itg3200.txt
@@ -0,0 +1,22 @@
+* InvenSense ITG-3200 gyroscope
+
+http://www.invensense.com/mems/gyro/itg3200.html
+
+Required properties:
+
+ - compatible : should be "invensense,itg3200"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+ - interrupts : interrupt mapping for GPIO IRQ
+
+Example:
+
+itg3200@68 {
+ compatible = "invensense,itg3200";
+ reg = <0x68>;
+ interrupt-parent = <>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b2635c5..01bf752 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -44,6 +44,7 @@ ibm International Business Machines (IBM)
idtIntegrated Device Technologies, Inc.
imgImagination Technologies Ltd.
intercontrol Inter Control Group
+invensense InvenSense
islIntersil
karo Ka-Ro electronics GmbH
lg LG Corporation
diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
index 4d3f3b9..adbf20d 100644
--- a/drivers/iio/gyro/itg3200_core.c
+++ b/drivers/iio/gyro/itg3200_core.c
@@ -374,10 +374,19 @@ static const struct i2c_device_id itg3200_id[] = {
};
MODULE_DEVICE_TABLE(i2c, itg3200_id);
+#ifdef CONFIG_OF
+static const struct of_device_id itg3200_of_match[] = {
+ { .compatible = "invensense,itg3200", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, itg3200_of_match);
+#endif
+
static struct i2c_driver itg3200_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "itg3200",
+ .of_match_table = of_match_ptr(itg3200_of_match),
},
.id_table = itg3200_id,
.probe = itg3200_probe,
--
1.8.3.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: linux-next: build failure after merge of the tip tree
On Sat, Jan 18, 2014 at 11:14:57AM -0800, H. Peter Anvin wrote: > >> Could something like this work? > >> > >>local_irq_enable(); > >>mwait_idle_with_hints(0,0); > >> > This means an interrupt window is open and we can take an interrupt > between checking need_resched and the MWAIT, which couldn't happen with > __sti_mwait(). > > Are we sure that is actually safe? current_set_polling_and_test() vs resched_task() should be good that way, but I've got a terrible head-ache today so don't rely on anything much I say. -- 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 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Sat, Jan 18, 2014 at 01:41:36PM +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 04:25:48AM -0800, Paul E. McKenney wrote:
> > On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
> > > On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
> > > > OK, I will bite... Aside from fine-grained code timing, what code could
> > > > you write to tell the difference between a real one-byte store and an
> > > > RMW emulating that store?
> > >
> > > Why isn't fine-grained code timing an issue? I'm sure Alpha people will
> > > love it when their machine magically keels over every so often.
> > >
> > > Suppose we have two bytes in a word that get concurrent updates:
> > >
> > > union {
> > > struct {
> > > u8 a;
> > > u8 b;
> > > };
> > > int word;
> > > } ponies = { .word = 0, };
> > >
> > > then two threads concurrently do:
> > >
> > > CPU0: CPU1:
> > >
> > > ponies.a = 5 ponies.b = 10
> > >
> > >
> > > At which point you'd expect: a == 5 && b == 10
> > >
> > > However, with a rmw you could end up like:
> > >
> > >
> > > load r, ponies.word
> > > load r, ponies.word
> > > and r, ~0xFF
> > > or r, 5
> > > store ponies.word, r
> > > and r, ~0xFF00
> > > or r, 10 << 8
> > > store ponies.word, r
> > >
> > > which gives: a == 0 && b == 10
> > >
> > > The same can be had on a single CPU if you make the second RMW an
> > > interrupt.
> > >
> > >
> > > In fact, we recently had such a RMW issue on PPC64 although from a
> > > slightly different angle, but we managed to hit it quite consistently.
> > > See commit ba1f14fbe7096.
> > >
> > > The thing is, if we allow the above RMW 'atomic' store, we have to be
> > > _very_ careful that there cannot be such overlapping stores, otherwise
> > > things will go BOOM!
> > >
> > > However, if we already have to make sure there's no overlapping stores,
> > > we might as well write a wide store and not allow the narrow stores to
> > > begin with, to force people to think about the issue.
> >
> > Ah, I was assuming atomic rmw, which for Alpha would be implemented using
> > the LL and SC instructions. Yes, lots of overhead, but if the CPU
> > designers chose not to provide a load/store byte...
>
> I don't see how ll/sc will help any. Suppose we do the a store as
> smp_store_release() using ll/sc but the b store is unaware and doesn't
> do an ll/sc.
>
> Then we're still up shit creek without no paddle.
>
> Whatever you're going to do, you need to be intimately aware of what the
> other bits in your word are doing.
Yes, this requires that -all- updates to the fields in the machine word
in question use atomic rmw. Which would not be pretty from a core-code
perspective. Hence my suggestion of ceasing Linux-kernel support for
DEC Alpha CPUs that don't support byte operations. Also need 16-bit
operations as well, of course...
Thanx, Paul
--
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] Adding hyperv.h to uapi headers
Bjarke Istrup Pedersen schreef op za 18-01-2014 om 20:48 [+]: > This patch adds the hyperv.h header to the uapi folder, and adds it to the > Kbuild file. > Doing this enables compiling userspace Hyper-V tools using the installed > headers. > > Signed-off-by: Bjarke Istrup Pedersen > --- > include/uapi/linux/Kbuild |1 + > include/uapi/linux/hyperv.h | 1469 > +++ > 2 files changed, 1470 insertions(+) > create mode 100644 include/uapi/linux/hyperv.h Now we have two identical files: include/linux/hyperv.h and include/uapi/linux/hyperv.h. That seems sub-optimal at best. Paul Bolle -- 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] xen/grant-table: Avoid m2p_override during mapping
On 13/01/14 19:08, Zoltan Kiss wrote:
@@ -284,8 +287,37 @@ static int map_grant_pages(struct grant_map *map)
}
pr_debug("map %d+%d\n", map->index, map->count);
- err = gnttab_map_refs(map->map_ops, use_ptemod ? map->kmap_ops : NULL,
- map->pages, map->count);
+ err = gnttab_map_refs(map->map_ops, NULL, map->pages, map->count);
+ if (err)
+ return err;
+
+ if (!in_interrupt() && paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE) {
+ arch_enter_lazy_mmu_mode();
+ lazy = true;
+ }
+
+ for (i = 0; i < map->count; i++) {
+ /* Do not add to override if the map failed. */
+ if (map->map_ops[i].status)
+ continue;
+
+ if (map->map_ops[i].flags & GNTMAP_contains_pte) {
+ pte = (pte_t *)
(mfn_to_virt(PFN_DOWN(map->map_ops[i].host_addr)) +
+ (map->map_ops[i].host_addr & ~PAGE_MASK));
+ mfn = pte_mfn(*pte);
+ } else {
+ mfn = PFN_DOWN(map->map_ops[i].dev_bus_addr);
+ }
+ err = m2p_add_override(mfn,
+ map->pages[i],
+ use_ptemod ? >kmap_ops[i] : NULL);
+ if (err)
+ break;
+ }
+
+ if (lazy)
+ arch_leave_lazy_mmu_mode();
+
if (err)
return err;
This patch has a fundamental problem here: we change the pfn in
gnttab_map_refs, then fetch it in m2p_override again, but then we have a
different one than we need. This causes Dom0 crash. I will send a new
version to fix that.
Zoli
--
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] Adding hyperv.h to uapi headers
This patch adds the hyperv.h header to the uapi folder, and adds it to the
Kbuild file.
Doing this enables compiling userspace Hyper-V tools using the installed
headers.
Signed-off-by: Bjarke Istrup Pedersen
---
include/uapi/linux/Kbuild |1 +
include/uapi/linux/hyperv.h | 1469 +++
2 files changed, 1470 insertions(+)
create mode 100644 include/uapi/linux/hyperv.h
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 33d2b8f..6389736 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -139,6 +139,7 @@ header-y += hid.h
header-y += hiddev.h
header-y += hidraw.h
header-y += hpet.h
+header-y += hyperv.h
header-y += hysdn_if.h
header-y += i2c-dev.h
header-y += i2c.h
diff --git a/include/uapi/linux/hyperv.h b/include/uapi/linux/hyperv.h
new file mode 100644
index 000..15da677
--- /dev/null
+++ b/include/uapi/linux/hyperv.h
@@ -0,0 +1,1469 @@
+/*
+ *
+ * Copyright (c) 2011, Microsoft Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Authors:
+ * Haiyang Zhang
+ * Hank Janssen
+ * K. Y. Srinivasan
+ *
+ */
+
+#ifndef _HYPERV_H
+#define _HYPERV_H
+
+#include
+
+/*
+ * Framework version for util services.
+ */
+#define UTIL_FW_MINOR 0
+
+#define UTIL_WS2K8_FW_MAJOR 1
+#define UTIL_WS2K8_FW_VERSION (UTIL_WS2K8_FW_MAJOR << 16 | UTIL_FW_MINOR)
+
+#define UTIL_FW_MAJOR 3
+#define UTIL_FW_VERSION (UTIL_FW_MAJOR << 16 | UTIL_FW_MINOR)
+
+
+/*
+ * Implementation of host controlled snapshot of the guest.
+ */
+
+#define VSS_OP_REGISTER 128
+
+enum hv_vss_op {
+ VSS_OP_CREATE = 0,
+ VSS_OP_DELETE,
+ VSS_OP_HOT_BACKUP,
+ VSS_OP_GET_DM_INFO,
+ VSS_OP_BU_COMPLETE,
+ /*
+* Following operations are only supported with IC version >= 5.0
+*/
+ VSS_OP_FREEZE, /* Freeze the file systems in the VM */
+ VSS_OP_THAW, /* Unfreeze the file systems */
+ VSS_OP_AUTO_RECOVER,
+ VSS_OP_COUNT /* Number of operations, must be last */
+};
+
+
+/*
+ * Header for all VSS messages.
+ */
+struct hv_vss_hdr {
+ __u8 operation;
+ __u8 reserved[7];
+} __attribute__((packed));
+
+
+/*
+ * Flag values for the hv_vss_check_feature. Linux supports only
+ * one value.
+ */
+#define VSS_HBU_NO_AUTO_RECOVERY 0x0005
+
+struct hv_vss_check_feature {
+ __u32 flags;
+} __attribute__((packed));
+
+struct hv_vss_check_dm_info {
+ __u32 flags;
+} __attribute__((packed));
+
+struct hv_vss_msg {
+ union {
+ struct hv_vss_hdr vss_hdr;
+ int error;
+ };
+ union {
+ struct hv_vss_check_feature vss_cf;
+ struct hv_vss_check_dm_info dm_info;
+ };
+} __attribute__((packed));
+
+/*
+ * An implementation of HyperV key value pair (KVP) functionality for Linux.
+ *
+ *
+ * Copyright (C) 2010, Novell, Inc.
+ * Author : K. Y. Srinivasan
+ *
+ */
+
+/*
+ * Maximum value size - used for both key names and value data, and includes
+ * any applicable NULL terminators.
+ *
+ * Note: This limit is somewhat arbitrary, but falls easily within what is
+ * supported for all native guests (back to Win 2000) and what is reasonable
+ * for the IC KVP exchange functionality. Note that Windows Me/98/95 are
+ * limited to 255 character key names.
+ *
+ * MSDN recommends not storing data values larger than 2048 bytes in the
+ * registry.
+ *
+ * Note: This value is used in defining the KVP exchange message - this value
+ * cannot be modified without affecting the message size and compatibility.
+ */
+
+/*
+ * bytes, including any null terminators
+ */
+#define HV_KVP_EXCHANGE_MAX_VALUE_SIZE (2048)
+
+
+/*
+ * Maximum key size - the registry limit for the length of an entry name
+ * is 256 characters, including the null terminator
+ */
+
+#define HV_KVP_EXCHANGE_MAX_KEY_SIZE(512)
+
+/*
+ * In Linux, we implement the KVP functionality in two components:
+ * 1) The kernel component which is packaged as part of the hv_utils driver
+ * is responsible for communicating with the host and responsible for
+ * implementing the host/guest protocol. 2) A user level daemon that is
+ * responsible for data gathering.
+ *
+ * Host/Guest Protocol: The host iterates over an index and expects the guest
+ * to assign a key name to the index and
Contract Agreement Breach
Dear Attorney, We are a Production, publishing and marketing company in Japan. We have a breach of intellectual property agreement matter in your jurisdiction, we can forward you the agreement and other party information for your review to enable you run a conflict check. Yours Sincerely, Yoshiko Tomoko Manager Shinchosha Publishing Co., Ltd. 71 Yaraicho, Shinjuku-ku, Tokyo 162-8711, Japan Tel: +81333716411 -- 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] iio: mxs-lradc: remove useless check
On Saturday, January 18, 2014 at 08:05:18 PM, Alexandre Belloni wrote:
> Checking the channel number is useless since mxs_lradc_read_raw() is called
> from a controlled environment and the driver is responsible for filing the
> struct iio_chan_spec.
>
> Signed-off-by: Alexandre Belloni
> ---
> drivers/staging/iio/adc/mxs-lradc.c | 4
> 1 file changed, 4 deletions(-)
Changelog's missing ;-)
Acked-by: Marek Vasut
> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
> b/drivers/staging/iio/adc/mxs-lradc.c index 7fc66a6a6e36..d304156ca2f7
> 100644
> --- a/drivers/staging/iio/adc/mxs-lradc.c
> +++ b/drivers/staging/iio/adc/mxs-lradc.c
> @@ -897,10 +897,6 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
> {
> struct mxs_lradc *lradc = iio_priv(iio_dev);
>
> - /* Check for invalid channel */
> - if (chan->channel > LRADC_MAX_TOTAL_CHANS)
> - return -EINVAL;
> -
> switch (m) {
> case IIO_CHAN_INFO_RAW:
> if (chan->type == IIO_TEMP)
Best regards,
Marek Vasut
--
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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
On 01/17/2014 06:34 AM, David Laight wrote: > Can you try the patch I posted that stops the ownership on LINK TRBs > being changed before that on the linked-to TRB? Please disregard my earlier post about the patch not applying cleanly. That was the usual html corruption, so I found the original on the usb list and it was okay. Sadly, the patch didn't fix the ASMedia lockup behavior, however :( I did notice that the lockup occurred only when copying *to* the usb3 drive, and not when copying from it. I think that may be new behavior but I can't swear to it. Just to confirm, here are the first few lines of the patch I used. Please let me know if it's the wrong patch: diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 53c2e29..589d336 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2928,6 +2928,11 @@ static void queue_trb(struct xhci_hcd *xhci, struct xhci_ring *ring, struct xhci_generic_trb *trb; trb = ring-enqueue-generic; + + field4 = (field4 ~TRB_CYCLE) | ring-cycle_state; + if (trb == ring-enqueue_first-generic) + field4 ^= TRB_CYCLE; + trb-field[0] = cpu_to_le32(field1); -- 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: 3.12.8 poor network performance x86_64
On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote: > I recently upgraded the Kernel from version 3.10 to latest stable > 3.12.8, did the usual "make oldconfig" (resulting config attached). > > But now I noticed some _really_ low network performance. Try: sysctl net.ipv4.tcp_limit_output_bytes=262144 Holger -- 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
On 01/18/2014 07:21 AM, Mike Galbraith wrote: > On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote: >> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote: >>> >>> I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on >>> Q6600 box. See below for an alternative. >> >> Urgh, I see, we call the idle arch_cpu_idle() callback with irqs >> disabled. >> >> Could something like this work? >> >> local_irq_enable(); >> mwait_idle_with_hints(0,0); >> >> The interrupt enable window is slightly larger, but I'm not immediately >> seeing a problem with that. > > Yup, works just fine. Less is more. > > Nice to see a _progression_ in the pipe too btw. > This means an interrupt window is open and we can take an interrupt between checking need_resched and the MWAIT, which couldn't happen with __sti_mwait(). Are we sure that is actually safe? -hpa -- 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: ipv4_dst_destroy panic regression after 3.10.15
> On Fri, Jan 17, 2014 at 11:16 PM, dormando wrote: > >> On Fri, 2014-01-17 at 22:49 -0800, Eric Dumazet wrote: > >> > On Fri, 2014-01-17 at 17:25 -0800, dormando wrote: > >> > > Hi, > >> > > > >> > > Upgraded a few kernels to the latest 3.10 stable tree while tracking > >> > > down > >> > > a rare kernel panic, seems to have introduced a much more frequent > >> > > kernel > >> > > panic. Takes anywhere from 4 hours to 2 days to trigger: > >> > > > >> > > <4>[196727.311203] general protection fault: [#1] SMP > >> > > <4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan > >> > > bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode > >> > > ipmi_watchdog ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis > >> > > tpm tpm_bios ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit > >> > > ixgbe ptp pps_core mdio > >> > > <4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 > >> > > #1 > >> > > <4>[196727.311344] Hardware name: Supermicro > >> > > X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013 > >> > > <4>[196727.311364] task: 885e6f069700 ti: 885e6f072000 > >> > > task.ti: 885e6f072000 > >> > > <4>[196727.311377] RIP: 0010:[] > >> > > [] ipv4_dst_destroy+0x4f/0x80 > >> > > <4>[196727.311399] RSP: 0018:885effd23a70 EFLAGS: 00010282 > >> > > <4>[196727.311409] RAX: dead00200200 RBX: 8854c398ecc0 RCX: > >> > > 0040 > >> > > <4>[196727.311423] RDX: dead00100100 RSI: dead00100100 RDI: > >> > > dead00200200 > >> > > <4>[196727.311437] RBP: 885effd23a80 R08: 815fd9e0 R09: > >> > > 885d5a590800 > >> > > <4>[196727.311451] R10: R11: R12: > >> > > > >> > > <4>[196727.311464] R13: 81c8c280 R14: R15: > >> > > 880e85ee16ce > >> > > <4>[196727.311510] FS: () > >> > > GS:885effd2() knlGS: > >> > > <4>[196727.311554] CS: 0010 DS: ES: CR0: 80050033 > >> > > <4>[196727.311581] CR2: 7a46751eb000 CR3: 005e65688000 CR4: > >> > > 000407e0 > >> > > <4>[196727.311625] DR0: DR1: DR2: > >> > > > >> > > <4>[196727.311669] DR3: DR6: 0ff0 DR7: > >> > > 0400 > >> > > <4>[196727.311713] Stack: > >> > > <4>[196727.311733] 8854c398ecc0 8854c398ecc0 885effd23ab0 > >> > > 815b7f42 > >> > > <4>[196727.311784] 88be6595bc00 8854c398ecc0 > >> > > 8854c398ecc0 > >> > > <4>[196727.311834] 885effd23ad0 815b86c6 885d5a590800 > >> > > 8816827821c0 > >> > > <4>[196727.311885] Call Trace: > >> > > <4>[196727.311907] > >> > > <4>[196727.311912] [] dst_destroy+0x32/0xe0 > >> > > <4>[196727.311959] [] dst_release+0x56/0x80 > >> > > <4>[196727.311986] [] tcp_v4_do_rcv+0x2a5/0x4a0 > >> > > <4>[196727.312013] [] tcp_v4_rcv+0x7da/0x820 > >> > > <4>[196727.312041] [] ? ip_rcv_finish+0x360/0x360 > >> > > <4>[196727.312070] [] ? nf_hook_slow+0x7d/0x150 > >> > > <4>[196727.312097] [] ? ip_rcv_finish+0x360/0x360 > >> > > <4>[196727.312125] [] > >> > > ip_local_deliver_finish+0xb2/0x230 > >> > > <4>[196727.312154] [] ip_local_deliver+0x4a/0x90 > >> > > <4>[196727.312183] [] ip_rcv_finish+0x119/0x360 > >> > > <4>[196727.312212] [] ip_rcv+0x22b/0x340 > >> > > <4>[196727.312242] [] ? > >> > > macvlan_broadcast+0x160/0x160 [macvlan] > >> > > <4>[196727.312275] [] > >> > > __netif_receive_skb_core+0x512/0x640 > >> > > <4>[196727.312308] [] ? kmem_cache_alloc+0x13b/0x150 > >> > > <4>[196727.312338] [] __netif_receive_skb+0x21/0x70 > >> > > <4>[196727.312368] [] netif_receive_skb+0x31/0xa0 > >> > > <4>[196727.312397] [] napi_gro_receive+0xe8/0x140 > >> > > <4>[196727.312433] [] ixgbe_poll+0x551/0x11f0 > >> > > [ixgbe] > >> > > <4>[196727.312463] [] ? ip_rcv+0x22b/0x340 > >> > > <4>[196727.312491] [] net_rx_action+0x111/0x210 > >> > > <4>[196727.312521] [] ? > >> > > __netif_receive_skb+0x21/0x70 > >> > > <4>[196727.312552] [] __do_softirq+0xd0/0x270 > >> > > <4>[196727.312583] [] call_softirq+0x1c/0x30 > >> > > <4>[196727.312613] [] do_softirq+0x55/0x90 > >> > > <4>[196727.312640] [] irq_exit+0x55/0x60 > >> > > <4>[196727.312668] [] do_IRQ+0x63/0xe0 > >> > > <4>[196727.312696] [] common_interrupt+0x6a/0x6a > >> > > <4>[196727.312722] > >> > > <4>[196727.312727] [] ? default_idle+0x20/0xe0 > >> > > <4>[196727.312775] [] arch_cpu_idle+0xf/0x20 > >> > > <4>[196727.312803] [] cpu_startup_entry+0xc0/0x270 > >> > > <4>[196727.312833] [] start_secondary+0x1f9/0x200 > >> > > <4>[196727.312860] Code: 4a 9f e9 81 e8 13 cb 0c 00 48 8b 93 b0 00 00 > >> > > 00 48 bf 00 02 20 00 00 00 ad de 48 8b 83 b8 00 00 00 48 be 00 01 10 > >> > > 00 00 00 ad de <48> 89 42 08 48 89 10 48 89 bb b8 00 00 00 48 c7 c7 4a > >> > > 9f e9 81 > >> > > <1>[196727.313071] RIP []
[PATCH v2] iio: mxs-lradc: remove useless check
Checking the channel number is useless since mxs_lradc_read_raw() is called from
a controlled environment and the driver is responsible for filing the struct
iio_chan_spec.
Signed-off-by: Alexandre Belloni
---
drivers/staging/iio/adc/mxs-lradc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 7fc66a6a6e36..d304156ca2f7 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -897,10 +897,6 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
{
struct mxs_lradc *lradc = iio_priv(iio_dev);
- /* Check for invalid channel */
- if (chan->channel > LRADC_MAX_TOTAL_CHANS)
- return -EINVAL;
-
switch (m) {
case IIO_CHAN_INFO_RAW:
if (chan->type == IIO_TEMP)
--
1.8.3.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: kmem_cache_alloc panic in 3.10+
> On Sat, 2014-01-18 at 00:44 -0800, dormando wrote: > > Hello again! > > > > We've had a rare crash that's existed between 3.10.0 and 3.10.15 at least > > (trying newer stables now, but I can't tell if it was fixed, and it takes > > weeks to reproduce). > > > > Unfortunately I can only get 8k back from pstore. The panic looks a bit > > longer than that is caught in the log, but the bottom part is almost > > always this same trace as this one: > > > > Panic#6 Part1 > > <4>[1197485.199166] [] tcp_push+0x6c/0x90 > > <4>[1197485.199171] [] tcp_sendmsg+0x109/0xd40 > > <4>[1197485.199179] [] ? put_page+0x35/0x40 > > <4>[1197485.199185] [] inet_sendmsg+0x45/0xb0 > > <4>[1197485.199191] [] sock_aio_write+0x11e/0x130 > > <4>[1197485.199196] [] ? inet_recvmsg+0x4f/0x80 > > <4>[1197485.199203] [] do_sync_readv_writev+0x6d/0xa0 > > <4>[1197485.199209] [] do_readv_writev+0xfb/0x2f0 > > <4>[1197485.199215] [] ? __free_pages+0x35/0x40 > > <4>[1197485.199220] [] ? free_pages+0x46/0x50 > > <4>[1197485.199226] [] ? SyS_mincore+0x152/0x690 > > <4>[1197485.199231] [] vfs_writev+0x48/0x60 > > <4>[1197485.199236] [] SyS_writev+0x5f/0xd0 > > <4>[1197485.199243] [] system_call_fastpath+0x16/0x1b > > <4>[1197485.199247] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 > > 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b > > 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c > > <1>[1197485.199290] RIP [] kmem_cache_alloc+0x5a/0x130 > > <4>[1197485.199296] RSP > > <4>[1197485.199299] CR2: 0001 > > <4>[1197485.199343] ---[ end trace 90fee06aa40b7304 ]--- > > <1>[1197485.263911] BUG: unable to handle kernel paging request at > > 0001 > > <1>[1197485.263923] IP: [] kmem_cache_alloc+0x5a/0x130 > > <4>[1197485.263932] PGD 3f43e5c067 PUD 0 > > <4>[1197485.263937] Oops: [#5] SMP > > <4>[1197485.263941] Modules linked in: ntfs vfat msdos fat macvlan bridge > > coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode sb_edac > > edac_core lpc_ich mfd_core ixgbe igb i2c_algo_bit mdio ptp pps_core > > <4>[1197485.263966] CPU: 0 PID: 233846 Comm: cache-worker Tainted: G D > > 3.10.15 #1 > > <4>[1197485.263972] Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 2.0a > > 03/07/2013 > > <4>[1197485.263976] task: 883427f9dc00 ti: 8830d4312000 task.ti: > > 8830d4312000 > > <4>[1197485.263982] RIP: 0010:[] [] > > kmem_cache_alloc+0x5a/0x130 > > <4>[1197485.263990] RSP: 0018:881fffc038c8 EFLAGS: 00010286 > > <4>[1197485.263994] RAX: RBX: 81c8c740 RCX: > > > > <4>[1197485.263999] RDX: 29273024 RSI: 0020 RDI: > > 00015680 > > <4>[1197485.264004] RBP: 881fffc03908 R08: 881fffc15680 R09: > > 815bdd4b > > <4>[1197485.264009] R10: 881c65d21800 R11: R12: > > 881fff803800 > > <4>[1197485.264014] R13: 0001 R14: R15: > > > > <4>[1197485.264019] FS: 7f8d855eb700() GS:881fffc0() > > knlGS: > > <4>[1197485.264024] CS: 0010 DS: ES: CR0: 80050033 > > <4>[1197485.264028] CR2: 0001 CR3: 00308f258000 CR4: > > 000407f0 > > <4>[1197485.264032] DR0: DR1: DR2: > > > > <4>[1197485.264037] DR3: DR6: 0ff0 DR7: > > 0400 > > <4>[1197485.264041] Stack: > > <4>[1197485.264044] 881fffc03928 0020815d0d95 881fffc03938 > > 81c8c740 > > <4>[1197485.264050] 881fce21 0001 > > > > <4>[1197485.264056] 881fffc03958 815bdd4b 881fffc039a8 > > > > <4>[1197485.264063] Call Trace: > > <4>[1197485.264066] > > <4>[1197485.264069] [] dst_alloc+0x5b/0x190 > > <4>[1197485.264080] [] rt_dst_alloc+0x4c/0x50 > > <4>[1197485.264085] [] __ip_route_output_key+0x270/0x880 > > <4>[1197485.264092] [] ? try_to_wake_up+0x23e/0x2b0 > > <4>[1197485.264097] [] ip_route_output_flow+0x27/0x60 > > <4>[1197485.264102] [] ip_queue_xmit+0x36a/0x390 > > <4>[1197485.264108] [] tcp_transmit_skb+0x485/0x890 > > <4>[1197485.264113] [] tcp_send_ack+0xf1/0x130 > > <4>[1197485.264118] [] __tcp_ack_snd_check+0x5e/0xa0 > > <4>[1197485.264123] [] tcp_rcv_state_process+0x8b2/0xb20 > > <4>[1197485.264128] [] tcp_v4_do_rcv+0x191/0x4f0 > > <4>[1197485.264133] [] tcp_v4_rcv+0x5fc/0x750 > > <4>[1197485.264138] [] ? ip_rcv+0x350/0x350 > > <4>[1197485.264143] [] ? nf_hook_slow+0x7d/0x160 > > <4>[1197485.264147] [] ? ip_rcv+0x350/0x350 > > <4>[1197485.264152] [] ip_local_deliver_finish+0xce/0x250 > > <4>[1197485.264156] [] ip_local_deliver+0x4c/0x80 > > <4>[1197485.264161] [] ip_rcv_finish+0x119/0x360 > > <4>[1197485.264165] [] ip_rcv+0x230/0x350 > > <4>[1197485.264170] [] > > __netif_receive_skb_core+0x477/0x600 > > <4>[1197485.264175]
Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
On 01/17/2014 06:34 AM, David Laight wrote: > From: walt >> Oy, Sarah! ;) I put the ASMedia adapter in my older amd64 machine, and, >> well, >> the stupid thing Just Works(TM) with kernel 3.12.7! (Yes, with the same disk >> docking station, too.) >> >> I can't believe the adapter works perfectly in a different computer. Have >> you >> seen this kind of thing before? > > Could be a horrid timing race between the cpu and xchi controller. > If the cpu manages to write a NOP or LINK TRB for a following transfer > before the controller polls the next entry (after raising the IRQ) > then the controller might process the LINK and then get confused > when it can't process the linked-to TRB. > This might not sound likely, but PCIe has significant latency. > Can you try the patch I posted that stops the ownership on LINK TRBs > being changed before that on the linked-to TRB? David, the patch doesn't apply cleanly to any 3.12.x sources I can find, including the latest git from Linus. Half of the hunks fail. Could you create a fresh patch against vanilla 3.12.8 so I can test it? Or point me to the correct kernel sources, perhaps. Thanks. -- 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: powerpc32 broken by ef1313deafb7
On 01/12/14 19:09, Benjamin Herrenschmidt wrote: Your attached config has ... CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" > So it's probably not what you wanted :-) No, it wasn't. I accidentally attached the wrong .config. I replied to this with the correct config last week. Did you get it? Here it is again. Just built against a fresh git pull and it's still happening for me... Thanks, Rob # # Automatically generated file; DO NOT EDIT. # Linux/powerpc 3.13.0-rc8 Kernel Configuration # # CONFIG_PPC64 is not set # # Processor support # CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_PPC_HAVE_PMU_SUPPORT=y # CONFIG_SMP is not set # CONFIG_PPC_DOORBELL is not set CONFIG_CPU_BIG_ENDIAN=y # CONFIG_CPU_LITTLE_ENDIAN is not set CONFIG_PPC32=y CONFIG_32BIT=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARCH_DMA_ADDR_T_64BIT is not set CONFIG_MMU=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set # CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set CONFIG_NR_IRQS=512 CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_PPC=y # CONFIG_GENERIC_CSUM is not set CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y # CONFIG_PPC_UDBG_16550 is not set # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_EPAPR_BOOT is not set # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_FHANDLE is not set # CONFIG_AUDIT is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL_OLD=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y # CONFIG_EXPERT is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_PCI_QUIRKS=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_JUMP_LABEL is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
Re: [PATCH resend 1/2] Documentation: move all DMA documentations into Documentaion/dma
On 01/16/14 09:59, Vinod Koul wrote: On Thu, Jan 16, 2014 at 06:50:04PM +0800, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Since there are already seven DMA documentations under the top Documentation/, it is better to create one dedicated directory for them. Well the problem is that not everything is same. Some of these mean how to use dma mapping API, couple are related to dmaengine, so clubing everything into "dma" doesnt sound right to me! Putting everything in the world in the top level directory isn't all flowers and kittens either. Where would be a _better_ place to move one of those files to? 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 resend 1/2] Documentation: move all DMA documentations into Documentaion/dma
On 01/16/14 04:50, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang Since there are already seven DMA documentations under the top Documentation/, it is better to create one dedicated directory for them. Signed-off-by: Hongbo Zhang Cc: David S. Miller Cc: Richard Henderson Cc: Jakub Jelinek Cc: James E.J. Bottomley Cc: Arthur Kepner Cc: sumit.sem...@linaro.org Cc: Vinod Koul Cc: Pierre Ossman Cc: Andy Shevchenko If the DMA guys merge this before I do, I note that it needs a 00-INDEX file for the new directory. (Otherwise I can add that when I forward it.) Acked-by: Rob Landley 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/
Hello
Hello, Good day. MY name is Jeniffer,(jenifferwillso...@yahoo.com)i am a young girl, with full of understanding,caring,I came across your contact i found interest in you,i believe you will be a good caring person. I will be happy if we get to know each other,i will send you my photo once i receive your email and everything about me, on that contact me directly to my email at (jenifferwillso...@yahoo.com) for easiest communication or you send me your email.Have a lovely and wonderful moment as I'm hoping to hear from you. Best Regards Jeniffer -- 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/
Help Needed
Hi, I am an expert of HP-UX (kernel and drivers), while being novice at linux. I am currently looking ways for quick ramp up so that I could contribute to linux community. Kindly provide pointers starting from where I could get the kernel sources. Appreciate help in advance. -Madhu -- 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: ipv4_dst_destroy panic regression after 3.10.15
On Fri, Jan 17, 2014 at 11:16 PM, dormando wrote: >> On Fri, 2014-01-17 at 22:49 -0800, Eric Dumazet wrote: >> > On Fri, 2014-01-17 at 17:25 -0800, dormando wrote: >> > > Hi, >> > > >> > > Upgraded a few kernels to the latest 3.10 stable tree while tracking down >> > > a rare kernel panic, seems to have introduced a much more frequent kernel >> > > panic. Takes anywhere from 4 hours to 2 days to trigger: >> > > >> > > <4>[196727.311203] general protection fault: [#1] SMP >> > > <4>[196727.311224] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan >> > > bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode >> > > ipmi_watchdog ipmi_devintf sb_edac edac_core lpc_ich mfd_core tpm_tis >> > > tpm tpm_bios ipmi_si ipmi_msghandler isci igb libsas i2c_algo_bit ixgbe >> > > ptp pps_core mdio >> > > <4>[196727.311333] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 3.10.26 #1 >> > > <4>[196727.311344] Hardware name: Supermicro >> > > X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013 >> > > <4>[196727.311364] task: 885e6f069700 ti: 885e6f072000 task.ti: >> > > 885e6f072000 >> > > <4>[196727.311377] RIP: 0010:[] [] >> > > ipv4_dst_destroy+0x4f/0x80 >> > > <4>[196727.311399] RSP: 0018:885effd23a70 EFLAGS: 00010282 >> > > <4>[196727.311409] RAX: dead00200200 RBX: 8854c398ecc0 RCX: >> > > 0040 >> > > <4>[196727.311423] RDX: dead00100100 RSI: dead00100100 RDI: >> > > dead00200200 >> > > <4>[196727.311437] RBP: 885effd23a80 R08: 815fd9e0 R09: >> > > 885d5a590800 >> > > <4>[196727.311451] R10: R11: R12: >> > > >> > > <4>[196727.311464] R13: 81c8c280 R14: R15: >> > > 880e85ee16ce >> > > <4>[196727.311510] FS: () GS:885effd2() >> > > knlGS: >> > > <4>[196727.311554] CS: 0010 DS: ES: CR0: 80050033 >> > > <4>[196727.311581] CR2: 7a46751eb000 CR3: 005e65688000 CR4: >> > > 000407e0 >> > > <4>[196727.311625] DR0: DR1: DR2: >> > > >> > > <4>[196727.311669] DR3: DR6: 0ff0 DR7: >> > > 0400 >> > > <4>[196727.311713] Stack: >> > > <4>[196727.311733] 8854c398ecc0 8854c398ecc0 885effd23ab0 >> > > 815b7f42 >> > > <4>[196727.311784] 88be6595bc00 8854c398ecc0 >> > > 8854c398ecc0 >> > > <4>[196727.311834] 885effd23ad0 815b86c6 885d5a590800 >> > > 8816827821c0 >> > > <4>[196727.311885] Call Trace: >> > > <4>[196727.311907] >> > > <4>[196727.311912] [] dst_destroy+0x32/0xe0 >> > > <4>[196727.311959] [] dst_release+0x56/0x80 >> > > <4>[196727.311986] [] tcp_v4_do_rcv+0x2a5/0x4a0 >> > > <4>[196727.312013] [] tcp_v4_rcv+0x7da/0x820 >> > > <4>[196727.312041] [] ? ip_rcv_finish+0x360/0x360 >> > > <4>[196727.312070] [] ? nf_hook_slow+0x7d/0x150 >> > > <4>[196727.312097] [] ? ip_rcv_finish+0x360/0x360 >> > > <4>[196727.312125] [] >> > > ip_local_deliver_finish+0xb2/0x230 >> > > <4>[196727.312154] [] ip_local_deliver+0x4a/0x90 >> > > <4>[196727.312183] [] ip_rcv_finish+0x119/0x360 >> > > <4>[196727.312212] [] ip_rcv+0x22b/0x340 >> > > <4>[196727.312242] [] ? macvlan_broadcast+0x160/0x160 >> > > [macvlan] >> > > <4>[196727.312275] [] >> > > __netif_receive_skb_core+0x512/0x640 >> > > <4>[196727.312308] [] ? kmem_cache_alloc+0x13b/0x150 >> > > <4>[196727.312338] [] __netif_receive_skb+0x21/0x70 >> > > <4>[196727.312368] [] netif_receive_skb+0x31/0xa0 >> > > <4>[196727.312397] [] napi_gro_receive+0xe8/0x140 >> > > <4>[196727.312433] [] ixgbe_poll+0x551/0x11f0 [ixgbe] >> > > <4>[196727.312463] [] ? ip_rcv+0x22b/0x340 >> > > <4>[196727.312491] [] net_rx_action+0x111/0x210 >> > > <4>[196727.312521] [] ? __netif_receive_skb+0x21/0x70 >> > > <4>[196727.312552] [] __do_softirq+0xd0/0x270 >> > > <4>[196727.312583] [] call_softirq+0x1c/0x30 >> > > <4>[196727.312613] [] do_softirq+0x55/0x90 >> > > <4>[196727.312640] [] irq_exit+0x55/0x60 >> > > <4>[196727.312668] [] do_IRQ+0x63/0xe0 >> > > <4>[196727.312696] [] common_interrupt+0x6a/0x6a >> > > <4>[196727.312722] >> > > <4>[196727.312727] [] ? default_idle+0x20/0xe0 >> > > <4>[196727.312775] [] arch_cpu_idle+0xf/0x20 >> > > <4>[196727.312803] [] cpu_startup_entry+0xc0/0x270 >> > > <4>[196727.312833] [] start_secondary+0x1f9/0x200 >> > > <4>[196727.312860] Code: 4a 9f e9 81 e8 13 cb 0c 00 48 8b 93 b0 00 00 00 >> > > 48 bf 00 02 20 00 00 00 ad de 48 8b 83 b8 00 00 00 48 be 00 01 10 00 00 >> > > 00 ad de <48> 89 42 08 48 89 10 48 89 bb b8 00 00 00 48 c7 c7 4a 9f e9 81 >> > > <1>[196727.313071] RIP [] ipv4_dst_destroy+0x4f/0x80 >> > > <4>[196727.313100] RSP >> > > <4>[196727.313377] ---[ end trace 64b3f14fae0f2e29 ]--- >> > > <0>[196727.380908] Kernel panic - not syncing: Fatal exception in >> > > interrupt >> > > >> > > >> > > ...
Re: kmem_cache_alloc panic in 3.10+
On Sat, 2014-01-18 at 08:29 -0800, Eric Dumazet wrote: > Hmm... > > Some dst seems to be destroyed twice. This likely screws slab allocator. > > Please try following untested patch : Forget it, after some coffee it makes no longer sense ;) -- 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] firewire: Enable remote DMA above 4 GB
This makes all of a machine's memory accessible to remote debugging via
FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link
layer controllers.
This requires actual support by the controller. The only ones currently
known to support it are Agere/LSI FW643. Most if not all other OHCI-1394
controllers do not implement the optional Physical Upper Bound register.
With them, RDMA will continue to be limited to the lowermost 4 GB.
firewire-ohci's startup message in the kernel log is augmented to tell
whether the controller does expose more than 4 GB to RDMA.
While OHCI-1394 allows for a maximum Physical Upper Bound of
0x'' (near 256 TB), this implementation sets it to
0x8000'' (128 TB) in order to avoid interference with applications
that require interrupt-served asynchronous request reception at
respectively low addresses.
Note, this change does not switch remote DMA on. It only increases the
range of remote access to all memory (instead of just 4 GB) whenever
remote DMA was switched on by other means. The latter is achieved by
setting firewire-ohci's remote_dma parameter, or if the physical DMA
filter is opened through firewire-sbp2.
Derived from patch "firewire: Enable physical DMA above 4GB" by
Peter Hurley from March 27, 2013.
Signed-off-by: Stefan Richter
---
v2: updated documentation, extended changelog
Documentation/debugging-via-ohci1394.txt | 13 +
drivers/firewire/core-transaction.c |6 +++---
drivers/firewire/core.h |3 +++
drivers/firewire/ohci.c |8 +---
4 files changed, 20 insertions(+), 10 deletions(-)
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -22,10 +22,12 @@ locations such as buffers like the print
Retrieving a full system memory dump is also possible over the FireWire,
using data transfer rates in the order of 10MB/s or more.
-Memory access is currently limited to the low 4G of physical address
-space which can be a problem on IA64 machines where memory is located
-mostly above that limit, but it is rarely a problem on more common
-hardware such as hardware based on x86, x86-64 and PowerPC.
+With most FireWire controllers, memory access is limited to the low 4 GB
+of physical address space. This can be a problem on IA64 machines where
+memory is located mostly above that limit, but it is rarely a problem on
+more common hardware such as x86, x86-64 and PowerPC. However, at least
+Agere/LSI FW643e and FW643e2 controllers are known to support access to
+physical addresses above 4 GB.
Together with a early initialization of the OHCI-1394 controller for debugging,
this facility proved most useful for examining long debugs logs in the printk
@@ -99,6 +101,9 @@ Step-by-step instructions for using fire
compliant, they are based on TI PCILynx chips and require drivers for Win-
dows operating systems.
+ The mentioned kernel log message contains ">4 GB phys DMA" in case of
+ OHCI-1394 controllers which support accesses above this limit.
+
2) Establish a working FireWire cable connection:
Any FireWire cable, as long at it provides electrically and mechanically
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -523,11 +523,11 @@ static DEFINE_SPINLOCK(address_handler_l
static LIST_HEAD(address_handler_list);
const struct fw_address_region fw_high_memory_region =
- { .start = 0x0001ULL, .end = 0xe000ULL, };
+ { .start = FW_MAX_PHYSICAL_RANGE, .end = 0xe000ULL, };
EXPORT_SYMBOL(fw_high_memory_region);
static const struct fw_address_region low_memory_region =
- { .start = 0xULL, .end = 0x0001ULL, };
+ { .start = 0xULL, .end = FW_MAX_PHYSICAL_RANGE, };
#if 0
const struct fw_address_region fw_private_region =
@@ -1217,7 +1217,7 @@ static void handle_low_memory(struct fw_
}
static struct fw_address_handler low_memory = {
- .length = 0x0001ULL,
+ .length = FW_MAX_PHYSICAL_RANGE,
.address_callback = handle_low_memory,
};
--- a/drivers/firewire/core.h
+++ b/drivers/firewire/core.h
@@ -237,6 +237,9 @@ static inline bool is_next_generation(in
#define LOCAL_BUS 0xffc0
+/* arbitrarily chosen maximum range for physical DMA: 128 TB */
+#define FW_MAX_PHYSICAL_RANGE (128ULL << 40)
+
void fw_core_handle_request(struct fw_card *card, struct fw_packet *request);
void fw_core_handle_response(struct fw_card *card, struct fw_packet *packet);
int fw_get_response_length(struct fw_request *request);
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2367,7 +2367,7 @@ static int ohci_enable(struct fw_card *c
reg_write(ohci, OHCI1394_FairnessControl, 0);
card->priority_budget_implemented = ohci->pri_req_max != 0;
- reg_write(ohci, OHCI1394_PhyUpperBound, 0x0001);
+
Re: kmem_cache_alloc panic in 3.10+
On Sat, 2014-01-18 at 00:44 -0800, dormando wrote: > Hello again! > > We've had a rare crash that's existed between 3.10.0 and 3.10.15 at least > (trying newer stables now, but I can't tell if it was fixed, and it takes > weeks to reproduce). > > Unfortunately I can only get 8k back from pstore. The panic looks a bit > longer than that is caught in the log, but the bottom part is almost > always this same trace as this one: > > Panic#6 Part1 > <4>[1197485.199166] [] tcp_push+0x6c/0x90 > <4>[1197485.199171] [] tcp_sendmsg+0x109/0xd40 > <4>[1197485.199179] [] ? put_page+0x35/0x40 > <4>[1197485.199185] [] inet_sendmsg+0x45/0xb0 > <4>[1197485.199191] [] sock_aio_write+0x11e/0x130 > <4>[1197485.199196] [] ? inet_recvmsg+0x4f/0x80 > <4>[1197485.199203] [] do_sync_readv_writev+0x6d/0xa0 > <4>[1197485.199209] [] do_readv_writev+0xfb/0x2f0 > <4>[1197485.199215] [] ? __free_pages+0x35/0x40 > <4>[1197485.199220] [] ? free_pages+0x46/0x50 > <4>[1197485.199226] [] ? SyS_mincore+0x152/0x690 > <4>[1197485.199231] [] vfs_writev+0x48/0x60 > <4>[1197485.199236] [] SyS_writev+0x5f/0xd0 > <4>[1197485.199243] [] system_call_fastpath+0x16/0x1b > <4>[1197485.199247] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 > 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 > <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c > <1>[1197485.199290] RIP [] kmem_cache_alloc+0x5a/0x130 > <4>[1197485.199296] RSP > <4>[1197485.199299] CR2: 0001 > <4>[1197485.199343] ---[ end trace 90fee06aa40b7304 ]--- > <1>[1197485.263911] BUG: unable to handle kernel paging request at > 0001 > <1>[1197485.263923] IP: [] kmem_cache_alloc+0x5a/0x130 > <4>[1197485.263932] PGD 3f43e5c067 PUD 0 > <4>[1197485.263937] Oops: [#5] SMP > <4>[1197485.263941] Modules linked in: ntfs vfat msdos fat macvlan bridge > coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode sb_edac > edac_core lpc_ich mfd_core ixgbe igb i2c_algo_bit mdio ptp pps_core > <4>[1197485.263966] CPU: 0 PID: 233846 Comm: cache-worker Tainted: G D >3.10.15 #1 > <4>[1197485.263972] Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 2.0a > 03/07/2013 > <4>[1197485.263976] task: 883427f9dc00 ti: 8830d4312000 task.ti: > 8830d4312000 > <4>[1197485.263982] RIP: 0010:[] [] > kmem_cache_alloc+0x5a/0x130 > <4>[1197485.263990] RSP: 0018:881fffc038c8 EFLAGS: 00010286 > <4>[1197485.263994] RAX: RBX: 81c8c740 RCX: > > <4>[1197485.263999] RDX: 29273024 RSI: 0020 RDI: > 00015680 > <4>[1197485.264004] RBP: 881fffc03908 R08: 881fffc15680 R09: > 815bdd4b > <4>[1197485.264009] R10: 881c65d21800 R11: R12: > 881fff803800 > <4>[1197485.264014] R13: 0001 R14: R15: > > <4>[1197485.264019] FS: 7f8d855eb700() GS:881fffc0() > knlGS: > <4>[1197485.264024] CS: 0010 DS: ES: CR0: 80050033 > <4>[1197485.264028] CR2: 0001 CR3: 00308f258000 CR4: > 000407f0 > <4>[1197485.264032] DR0: DR1: DR2: > > <4>[1197485.264037] DR3: DR6: 0ff0 DR7: > 0400 > <4>[1197485.264041] Stack: > <4>[1197485.264044] 881fffc03928 0020815d0d95 881fffc03938 > 81c8c740 > <4>[1197485.264050] 881fce21 0001 > > <4>[1197485.264056] 881fffc03958 815bdd4b 881fffc039a8 > > <4>[1197485.264063] Call Trace: > <4>[1197485.264066] > <4>[1197485.264069] [] dst_alloc+0x5b/0x190 > <4>[1197485.264080] [] rt_dst_alloc+0x4c/0x50 > <4>[1197485.264085] [] __ip_route_output_key+0x270/0x880 > <4>[1197485.264092] [] ? try_to_wake_up+0x23e/0x2b0 > <4>[1197485.264097] [] ip_route_output_flow+0x27/0x60 > <4>[1197485.264102] [] ip_queue_xmit+0x36a/0x390 > <4>[1197485.264108] [] tcp_transmit_skb+0x485/0x890 > <4>[1197485.264113] [] tcp_send_ack+0xf1/0x130 > <4>[1197485.264118] [] __tcp_ack_snd_check+0x5e/0xa0 > <4>[1197485.264123] [] tcp_rcv_state_process+0x8b2/0xb20 > <4>[1197485.264128] [] tcp_v4_do_rcv+0x191/0x4f0 > <4>[1197485.264133] [] tcp_v4_rcv+0x5fc/0x750 > <4>[1197485.264138] [] ? ip_rcv+0x350/0x350 > <4>[1197485.264143] [] ? nf_hook_slow+0x7d/0x160 > <4>[1197485.264147] [] ? ip_rcv+0x350/0x350 > <4>[1197485.264152] [] ip_local_deliver_finish+0xce/0x250 > <4>[1197485.264156] [] ip_local_deliver+0x4c/0x80 > <4>[1197485.264161] [] ip_rcv_finish+0x119/0x360 > <4>[1197485.264165] [] ip_rcv+0x230/0x350 > <4>[1197485.264170] [] __netif_receive_skb_core+0x477/0x600 > <4>[1197485.264175] [] __netif_receive_skb+0x27/0x70 > <4>[1197485.264180] [] process_backlog+0xf4/0x1e0 > <4>[1197485.264184] [] net_rx_action+0xf5/0x250 > <4>[1197485.264190] [] __do_softirq+0xef/0x270 >
Re: [PATCH 11/11] ext4: add cross rename support
On Sat, Jan 18, 2014 at 07:49:29AM +0100, Miklos Szeredi wrote:
> On Fri, Jan 17, 2014 at 11:08 PM, J. Bruce Fields
> wrote:
> > On Fri, Jan 17, 2014 at 11:53:07PM +1300, Michael Kerrisk (man-pages) wrote:
> >> >The following additional errors are defined for renameat2():
> >> >
> >> >EOPNOTSUPP
> >> > The filesystem does not support a flag in flags
> >>
> >> This is not the usual error for an invalid bit flag. Please make it EINVAL.
> >
> > I agree that EINVAL makes sense for an invalid bit flag.
> >
> > But renameat2() can also fail when the caller passes a perfectly valid
> > flags field but the paths resolve to a filesystem that doesn't support
> > the RENAME_EXCHANGE operation. EOPNOTSUPP looks more appropriate in
> > that case.
>
> OTOH, from the app's perspective, it makes little difference whether a
> particular kernel doesn't support the reanameat2 syscall, or it
> doesn't support RENAME_FOO flag or if it does support RENAME_FOO but
> not in all filesystems. In all those cases it has to just fall back
> to something supported and it doesn't matter *why* it wasn't
> supported.
Well, in theory it could allow an optimization:
if (kernel_has_foo) {
ret = rename(.,.,.,.,RENAME_FOO);
if (ret && errno == EINVAL)
kernel_has_foo = 0;
}
if (!kernel_has_foo)
fallback...
or maybe even:
if (kernel_has_foo && fs_has_foo[fsid])
ret = rename(.,.,.,.,RENAME_FOO);
if (ret && errno == EINVAL)
kernel_has_foo = 0;
if (ret && errno == EOPNOTSUPP)
fs_has_foo[fsid] = 0;
}
if (!kernel_has_foo || !fs_has_foo[fsid])
fallback...
which may both be of dubious value--unless, say, you're implementing a
network protocol and making this distinction to your client allows it to
save server round trips.
That may not be *totally* farfetched--if for example we added rename2 to
the nfs protocol then servers probably will be required to make this
sort of distinction per filesystem, exactly to allow client logic like
the above.
And as long as we can, I'd just rather give the caller more information
than less.
As for precedent for EOPNOTSUPP: grepping through man-pages the one
documented use of EOPNOTSUPP I see for filesystems is fallocate, for a
similar "filesystem doesn't support this operation" case. "git grep
EOPNOTSUPP fs/" in the kernel repo suggests there are many more such,
but I haven't tried to figure out what any of them are.
--b.
--
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 REGRESSION FIX] x86 idle: restore mwait_idle()
On Sat, 2014-01-18 at 10:33 +0100, Mike Galbraith wrote:
> On Fri, 2014-01-17 at 05:20 +0100, Mike Galbraith wrote:
>
> > taskset 0xc pipe-test 1
> >
> > 3.8.13 3.397977 usecs/loop -- avg 3.400336 588.2 KHz
> > master+4.798547 usecs/loop -- avg 4.791692 417.4 KHz
>
> Bah, those are apple/grape, these are apple/apple.
Or, to make it more correct for 3.10..13, add the clflush barriers as
well for afflicted CPUs.
idle: kill unnecessary mwait_idle() resched IPIs
Set/clear polling instead.
Q6600, pipe-test scheduling cross core:
3.8.13 487.2 KHz1.000
3.13.0-master415.5 KHz .852
3.13.0-master+ 415.2 KHz .852 + restore mwait_idle
3.13.0-master++ 488.5 KHz1.002 + restore mwait_idle + IPI fix
Signed-off-by: Mike Galbraith
Cc: # 3.10+
---
arch/x86/kernel/process.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -427,18 +427,21 @@ static int prefer_mwait_c1_over_halt(con
static void mwait_idle(void)
{
- if (!need_resched()) {
- if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+ if (!current_set_polling_and_test()) {
+ if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+ mb();
clflush((void *)_thread_info()->flags);
+ mb();
+ }
__monitor((void *)_thread_info()->flags, 0, 0);
- smp_mb();
if (!need_resched())
__sti_mwait(0, 0);
else
local_irq_enable();
} else
local_irq_enable();
+ __current_clr_polling();
}
void select_idle_routine(const struct cpuinfo_x86 *c)
--
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] firewire: Enable remote DMA above 4 GB
On Jan 18 Stefan Richter wrote: > This makes all of a machine's memory accessible to remote debugging via > FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link > layer controllers. > > This requires actual support by the controller. The only ones currently > known to support it are Agere/LSI FW643. Most if not all other OHCI-1394 > controllers do not implement the optional Physical Upper Bound register. > With them, RDMA will continue to be limited to the lowermost 4 GB. [...] PS, this patch does not switch remote DMA on. It only increases the range of remote access to all memory (instead of just 4 GB) _when_ remote DMA was switched on by other means. The latter is achieved by setting CONFIG_FIREWIRE_OHCI_REMOTE_DMA, or by a module parameter introduced by commit 8bc588e0e585 of linux1394.git, or if the physical DMA filter is opened through firewire-sbp2. -- Stefan Richter -=-- ---= =--=- http://arcgraph.de/sr/ -- 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] firewire: Enable remote DMA above 4 GB
This makes all of a machine's memory accessible to remote debugging via
FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link
layer controllers.
This requires actual support by the controller. The only ones currently
known to support it are Agere/LSI FW643. Most if not all other OHCI-1394
controllers do not implement the optional Physical Upper Bound register.
With them, RDMA will continue to be limited to the lowermost 4 GB.
firewire-ohci's startup message in the kernel log is augmented to tell
whether the controller does expose more than 4 GB to RDMA.
While OHCI-1394 allows for a maximum Physical Upper Bound of
0x'' (near 256 TB), this implementation sets it to
0x8000'' (128 TB) in order to avoid interference with applications
that require interrupt-served asynchronous request reception at
respectively low addresses.
Derived from patch "firewire: Enable physical DMA above 4GB" by
Peter Hurley from March 27, 2013.
Signed-off-by: Stefan Richter
---
drivers/firewire/core-transaction.c |6 +++---
drivers/firewire/core.h |3 +++
drivers/firewire/ohci.c |8 +---
3 files changed, 11 insertions(+), 6 deletions(-)
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -523,11 +523,11 @@ static DEFINE_SPINLOCK(address_handler_l
static LIST_HEAD(address_handler_list);
const struct fw_address_region fw_high_memory_region =
- { .start = 0x0001ULL, .end = 0xe000ULL, };
+ { .start = FW_MAX_PHYSICAL_RANGE, .end = 0xe000ULL, };
EXPORT_SYMBOL(fw_high_memory_region);
static const struct fw_address_region low_memory_region =
- { .start = 0xULL, .end = 0x0001ULL, };
+ { .start = 0xULL, .end = FW_MAX_PHYSICAL_RANGE, };
#if 0
const struct fw_address_region fw_private_region =
@@ -1217,7 +1217,7 @@ static void handle_low_memory(struct fw_
}
static struct fw_address_handler low_memory = {
- .length = 0x0001ULL,
+ .length = FW_MAX_PHYSICAL_RANGE,
.address_callback = handle_low_memory,
};
--- a/drivers/firewire/core.h
+++ b/drivers/firewire/core.h
@@ -237,6 +237,9 @@ static inline bool is_next_generation(in
#define LOCAL_BUS 0xffc0
+/* arbitrarily chosen maximum range for physical DMA: 128 TB */
+#define FW_MAX_PHYSICAL_RANGE (128ULL << 40)
+
void fw_core_handle_request(struct fw_card *card, struct fw_packet *request);
void fw_core_handle_response(struct fw_card *card, struct fw_packet *packet);
int fw_get_response_length(struct fw_request *request);
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2367,7 +2367,7 @@ static int ohci_enable(struct fw_card *c
reg_write(ohci, OHCI1394_FairnessControl, 0);
card->priority_budget_implemented = ohci->pri_req_max != 0;
- reg_write(ohci, OHCI1394_PhyUpperBound, 0x0001);
+ reg_write(ohci, OHCI1394_PhyUpperBound, FW_MAX_PHYSICAL_RANGE >> 16);
reg_write(ohci, OHCI1394_IntEventClear, ~0);
reg_write(ohci, OHCI1394_IntMaskClear, ~0);
@@ -3723,9 +3723,11 @@ static int pci_probe(struct pci_dev *dev
version = reg_read(ohci, OHCI1394_Version) & 0x00ff00ff;
ohci_notice(ohci,
"added OHCI v%x.%x device as card %d, "
- "%d IR + %d IT contexts, quirks 0x%x\n",
+ "%d IR + %d IT contexts, quirks 0x%x%s\n",
version >> 16, version & 0xff, ohci->card.index,
- ohci->n_ir, ohci->n_it, ohci->quirks);
+ ohci->n_ir, ohci->n_it, ohci->quirks,
+ reg_read(ohci, OHCI1394_PhyUpperBound) ?
+ ", >4 GB phys DMA" : "");
return 0;
--
Stefan Richter
-=-- ---= =--=-
http://arcgraph.de/sr/
--
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/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate
On 01/18/2014 04:28 PM, Tejun Heo wrote: On Sat, Jan 18, 2014 at 04:26:24PM +0100, Daniel Borkmann wrote: Unless there's gonna be another rc, I think it's already a bit too late for 3.14 anyway. I'll drop the net_cls part and rebase the changes on top of rc1 later on. I think that's 1 patch of your series, right? They overlap. I think this one could still go through net-next if you want, that would avoid a merge conflict. If there's gonna be another rc, I'll prolly just cherry-pick the commit from net-next and then rebase the rest on top of it. If there isn't gonna be another rc, I'm just gonna base everything on v3.14-rc1 which would include the patch from net-next. Ok, sounds good. Thanks Tejun. -- 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] of: add functions to count number of elements in a property
Am Samstag, 18. Januar 2014, 09:07:30 schrieb Rob Herring:
> On Sat, Jan 18, 2014 at 6:02 AM, Heiko Stübner wrote:
> > The need to know the number of array elements in a property is
> > a common pattern. To prevent duplication of open-coded implementations
> > add a helper static function that also centralises strict sanity
> > checking and DTB format details, as well as a set of wrapper functions
> > for u8, u16, u32 and u64.
> >
> > Suggested-by: Mark Rutland
> > Signed-off-by: Heiko Stuebner
> > ---
>
> Looks good. Do you plan to convert some users to use this?
My plan at the moment was to "just" use it for my mmio-sram-reserve stuff -
just wanted to make sure that this change is sane, before having to sent the
whole thing for each iteration.
I haven't yet looked where the other users, that Mark mentioned, are at :-)
Heiko
> > changes since v3:
> > address more comments from Rob Herring
> > - export the base function and inline the type-specific wrappers
> > changes since v2:
> > address more comments from Mark Rutland
> > - switch to of_property_count_elems_of_size
> > - use full_name instead of name in error message
> > changes since v1:
> > address comments from Rob Herring and Mark Rutland:
> > - provide a helper and a set of wrappers for u8-u64
> > - get rid of extra len variable, prop->length is enough
> > - include node name in error message
> >
> > Mark, does your Reviewed-by holds for this variant too?
> >
> > drivers/of/base.c | 32 ++
> > include/linux/of.h | 76
> > 2 files changed,
> > 108 insertions(+)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index f807d0e..21646c0 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -862,6 +862,38 @@ struct device_node *of_find_node_by_phandle(phandle
> > handle)>
> > EXPORT_SYMBOL(of_find_node_by_phandle);
> >
> > /**
> >
> > + * of_property_count_elems_of_size - Count the number of elements in a
> > property + *
> > + * @np:device node from which the property value is to be
> > read. + * @propname: name of the property to be searched.
> > + * @elem_size: size of the individual element
> > + *
> > + * Search for a property in a device node and count the number of
> > elements of + * size elem_size in it. Returns number of elements on
> > sucess, -EINVAL if the + * property does not exist or its length does not
> > match a multiple of u16 and + * -ENODATA if the property does not have a
> > value.
> > + */
> > +int of_property_count_elems_of_size(const struct device_node *np,
> > + const char *propname, int elem_size)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > +
> > + if (prop->length % elem_size != 0) {
> > + pr_err("size of %s in node %s is not a multiple of %d\n",
> > + propname, np->full_name, elem_size);
> > + return -EINVAL;
> > + }
> > +
> > + return prop->length / elem_size;
> > +}
> > +EXPORT_SYMBOL_GPL(of_property_count_elems_of_size);
> > +
> > +/**
> >
> > * of_find_property_value_of_size
> > *
> > * @np:device node from which the property value is to be
> > read.>
> > diff --git a/include/linux/of.h b/include/linux/of.h
> > index 276c546..293920d 100644
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@ -250,6 +250,8 @@ extern struct device_node *of_find_node_with_property(
> >
> > extern struct property *of_find_property(const struct device_node *np,
> >
> > const char *name,
> > int *lenp);
> >
> > +extern int of_property_count_elems_of_size(const struct device_node *np,
> > + const char *propname, int elem_size);
> >
> > extern int of_property_read_u32_index(const struct device_node *np,
> >
> >const char *propname,
> >u32 index, u32 *out_value);
> >
> > @@ -426,6 +428,12 @@ static inline struct device_node
> > *of_find_compatible_node(>
> > return NULL;
> >
> > }
> >
> > +static inline int of_property_count_elems_of_size(const struct
> > device_node *np, + const char *propname, int
> > elem_size)
> > +{
> > + return -ENOSYS;
> > +}
> > +
> >
> > static inline int of_property_read_u32_index(const struct device_node
> > *np,
> >
> > const char *propname, u32 index, u32 *out_value)
> >
> > {
> >
> > @@ -565,6 +573,74 @@ static inline int of_node_to_nid(struct device_node
> > *device) { return 0; }>
> > #endif
> >
> > /**
> >
> > + * of_property_count_u8_elems - Count the number of u8 elements in a
> >
Re: [PATCH 1/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate
On Sat, Jan 18, 2014 at 04:26:24PM +0100, Daniel Borkmann wrote: > >Unless there's gonna be another rc, I think it's already a bit too > >late for 3.14 anyway. I'll drop the net_cls part and rebase the > >changes on top of rc1 later on. > > I think that's 1 patch of your series, right? They overlap. > I think this one could still go through net-next if you want, that would > avoid a merge conflict. If there's gonna be another rc, I'll prolly just cherry-pick the commit from net-next and then rebase the rest on top of it. If there isn't gonna be another rc, I'm just gonna base everything on v3.14-rc1 which would include the patch from net-next. Thanks. -- tejun -- 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/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate
On 01/18/2014 04:10 PM, Tejun Heo wrote: Hey, On Sat, Jan 18, 2014 at 09:08:49AM +0800, Li Zefan wrote: Cc: Daniel Borkmann On 2014/1/18 2:11, Tejun Heo wrote: net_cls and net_prio are the only cgroups which are allowed to be built as modules. The savings from allowing the two controllers to be built as modules are tiny especially given that cgroup module support itself adds quite a bit of complexity. The following are the sizes of vmlinux with both built as module and both built as part of the kernel image with cgroup module support removed. textdatabss dec 202922072411496 1078476833488471 202934212412568 1078476833490757 The total difference is 2286 bytes. Given that none of other controllers has much chance of being made a module and that we're unlikely to add new modular controllers, the added complexity is simply not justifiable. As a first step to drop cgroup module support, this patch changes the two config options to bool from tristate and drops module related code from the two controllers. I sugguested Daniel to do this for net_cls, and the change has been in net-next. https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=fe1217c4f3f7d7cbf8efdd8dd5fdc7204a1d65a8 I was planning to remove module support after that change goes into upstream. :) Ooh, cool. :) Unless there's gonna be another rc, I think it's already a bit too late for 3.14 anyway. I'll drop the net_cls part and rebase the changes on top of rc1 later on. I think that's 1 patch of your series, right? I think this one could still go through net-next if you want, that would avoid a merge conflict. Best, Daniel -- 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
On Sat, 2014-01-18 at 13:44 +0100, Peter Zijlstra wrote: > On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote: > > > > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on > > Q6600 box. See below for an alternative. > > Urgh, I see, we call the idle arch_cpu_idle() callback with irqs > disabled. > > Could something like this work? > > local_irq_enable(); > mwait_idle_with_hints(0,0); > > The interrupt enable window is slightly larger, but I'm not immediately > seeing a problem with that. Yup, works just fine. Less is more. Nice to see a _progression_ in the pipe too btw. -Mike -- 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/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate
Hey, On Sat, Jan 18, 2014 at 09:08:49AM +0800, Li Zefan wrote: > Cc: Daniel Borkmann > > On 2014/1/18 2:11, Tejun Heo wrote: > > net_cls and net_prio are the only cgroups which are allowed to be > > built as modules. The savings from allowing the two controllers to be > > built as modules are tiny especially given that cgroup module support > > itself adds quite a bit of complexity. > > > > The following are the sizes of vmlinux with both built as module and > > both built as part of the kernel image with cgroup module support > > removed. > > > > textdatabss dec > > 202922072411496 1078476833488471 > > 202934212412568 1078476833490757 > > > > The total difference is 2286 bytes. Given that none of other > > controllers has much chance of being made a module and that we're > > unlikely to add new modular controllers, the added complexity is > > simply not justifiable. > > > > As a first step to drop cgroup module support, this patch changes the > > two config options to bool from tristate and drops module related code > > from the two controllers. > > > > I sugguested Daniel to do this for net_cls, and the change has been in > net-next. > > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=fe1217c4f3f7d7cbf8efdd8dd5fdc7204a1d65a8 > > I was planning to remove module support after that change goes into > upstream. :) Ooh, cool. :) Unless there's gonna be another rc, I think it's already a bit too late for 3.14 anyway. I'll drop the net_cls part and rebase the changes on top of rc1 later on. Thanks. -- tejun -- 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] of: add functions to count number of elements in a property
On Sat, Jan 18, 2014 at 6:02 AM, Heiko Stübner wrote:
> The need to know the number of array elements in a property is
> a common pattern. To prevent duplication of open-coded implementations
> add a helper static function that also centralises strict sanity
> checking and DTB format details, as well as a set of wrapper functions
> for u8, u16, u32 and u64.
>
> Suggested-by: Mark Rutland
> Signed-off-by: Heiko Stuebner
> ---
Looks good. Do you plan to convert some users to use this?
Rob
> changes since v3:
> address more comments from Rob Herring
> - export the base function and inline the type-specific wrappers
> changes since v2:
> address more comments from Mark Rutland
> - switch to of_property_count_elems_of_size
> - use full_name instead of name in error message
> changes since v1:
> address comments from Rob Herring and Mark Rutland:
> - provide a helper and a set of wrappers for u8-u64
> - get rid of extra len variable, prop->length is enough
> - include node name in error message
>
> Mark, does your Reviewed-by holds for this variant too?
>
> drivers/of/base.c | 32 ++
> include/linux/of.h | 76
>
> 2 files changed, 108 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..21646c0 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -862,6 +862,38 @@ struct device_node *of_find_node_by_phandle(phandle
> handle)
> EXPORT_SYMBOL(of_find_node_by_phandle);
>
> /**
> + * of_property_count_elems_of_size - Count the number of elements in a
> property
> + *
> + * @np:device node from which the property value is to be
> read.
> + * @propname: name of the property to be searched.
> + * @elem_size: size of the individual element
> + *
> + * Search for a property in a device node and count the number of elements of
> + * size elem_size in it. Returns number of elements on sucess, -EINVAL if the
> + * property does not exist or its length does not match a multiple of u16 and
> + * -ENODATA if the property does not have a value.
> + */
> +int of_property_count_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> +
> + if (prop->length % elem_size != 0) {
> + pr_err("size of %s in node %s is not a multiple of %d\n",
> + propname, np->full_name, elem_size);
> + return -EINVAL;
> + }
> +
> + return prop->length / elem_size;
> +}
> +EXPORT_SYMBOL_GPL(of_property_count_elems_of_size);
> +
> +/**
> * of_find_property_value_of_size
> *
> * @np:device node from which the property value is to be
> read.
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 276c546..293920d 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -250,6 +250,8 @@ extern struct device_node *of_find_node_with_property(
> extern struct property *of_find_property(const struct device_node *np,
> const char *name,
> int *lenp);
> +extern int of_property_count_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size);
> extern int of_property_read_u32_index(const struct device_node *np,
>const char *propname,
>u32 index, u32 *out_value);
> @@ -426,6 +428,12 @@ static inline struct device_node
> *of_find_compatible_node(
> return NULL;
> }
>
> +static inline int of_property_count_elems_of_size(const struct device_node
> *np,
> + const char *propname, int elem_size)
> +{
> + return -ENOSYS;
> +}
> +
> static inline int of_property_read_u32_index(const struct device_node *np,
> const char *propname, u32 index, u32 *out_value)
> {
> @@ -565,6 +573,74 @@ static inline int of_node_to_nid(struct device_node
> *device) { return 0; }
> #endif
>
> /**
> + * of_property_count_u8_elems - Count the number of u8 elements in a property
> + *
> + * @np:device node from which the property value is to be
> read.
> + * @propname: name of the property to be searched.
> + *
> + * Search for a property in a device node and count the number of u8 elements
> + * in it. Returns number of elements on sucess, -EINVAL if the property does
> + * not exist or its length does not match a multiple of u8 and -ENODATA if
> the
> + * property does not have a value.
> + */
> +static inline int of_property_count_u8_elems(const struct device_node *np,
> + const char *propname)
> +{
> + return of_property_count_elems_of_size(np,
Re: [PATCH v2 0/9] Phase out pci_enable_msi_block()
On Sat, Jan 18, 2014 at 07:38:55AM -0700, Bjorn Helgaas wrote: > On Sat, Jan 18, 2014 at 12:15 AM, Alexander Gordeev > wrote: > > On Fri, Jan 17, 2014 at 02:00:32PM -0700, Bjorn Helgaas wrote: > >> > As the release is supposedly this weekend, do you prefer > >> > the patches to go to your tree or to individual trees after > >> > the release? > >> > >> I'd be happy to merge them, except for the fact that they probably > >> wouldn't have any time in -next before I ask Linus to pull them. So > >> how about if we wait until after the release, ask the area maintainers > >> to take them, and if they don't take them, I'll put them in my tree > >> for v3.15? > > > > Patch 11 depends on patches 1-10, so I am not sure how to better handle it. > > Whatever works for you ;) > > > > I am only concerned with a regression fix "ahci: Fix broken fallback to > > single MSI mode" which would be nice to have in 3.14. But it seems pretty > > much too late. > > Tejun, if you want to ack that one, I can put it in either the first > 3.14 pull request or a subsequent one. Either way, since it's a > regression fix, we should be able to get it in 3.14. Acked-by: Tejun Heo Please feel free to route it any way you see fit. Thanks! -- tejun -- 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 0/9] Phase out pci_enable_msi_block()
On Sat, Jan 18, 2014 at 12:15 AM, Alexander Gordeev wrote: > On Fri, Jan 17, 2014 at 02:00:32PM -0700, Bjorn Helgaas wrote: >> > As the release is supposedly this weekend, do you prefer >> > the patches to go to your tree or to individual trees after >> > the release? >> >> I'd be happy to merge them, except for the fact that they probably >> wouldn't have any time in -next before I ask Linus to pull them. So >> how about if we wait until after the release, ask the area maintainers >> to take them, and if they don't take them, I'll put them in my tree >> for v3.15? > > Patch 11 depends on patches 1-10, so I am not sure how to better handle it. > Whatever works for you ;) > > I am only concerned with a regression fix "ahci: Fix broken fallback to > single MSI mode" which would be nice to have in 3.14. But it seems pretty > much too late. Tejun, if you want to ack that one, I can put it in either the first 3.14 pull request or a subsequent one. Either way, since it's a regression fix, we should be able to get it in 3.14. Bjorn -- 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: [v3.11][v3.12][v3.13][Regression] EISA: Initialize device before its resources
On Fri, Jan 17, 2014 at 6:35 PM, Joseph Salisbury
wrote:
> On 01/17/2014 05:19 PM, Bjorn Helgaas wrote:
>> On Fri, Jan 17, 2014 at 02:26:23PM -0500, Joseph Salisbury wrote:
>>> On 01/17/2014 12:02 PM, Bjorn Helgaas wrote:
On Thu, Jan 16, 2014 at 01:14:01PM -0500, Joseph Salisbury wrote:
> On 01/16/2014 01:12 PM, Bjorn Helgaas wrote:
>> On Thu, Jan 16, 2014 at 10:53 AM, Joseph Salisbury
>> wrote:
>>> Hi Bjorn,
>>>
>>> A kernel bug was opened against Ubuntu [0]. After a kernel bisect, it
>>> was found the following commit introduced this bug:
>> Sorry about that, and thanks for the report. Did you mean to include
>> URL for the bug?
> Yes, sorry about that:
> http://pad.lv/1251816
Hi Joseph,
Can you attach the 3.8.0-32-generic config (the one matching the successful
boot at https://launchpadlibrarian.net/156685076/BootDmesg.txt) to the bug?
>>> I attached the config file to the bug:
>>> https://launchpadlibrarian.net/162754666/config.common.ubuntu
>>>
>>> I also attached a tar file with the complete config directory for that
>>> kernel version.
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816/+attachment/3951156/+files/raring-config.tar
>> Thanks again. I attached the following reverts to launchpad. I screwed up
>> when doing those EISA changes. I'd like to squeeze these into my v3.14
>> merge request (probably early next week), so please test and let me know
>> if this fixes the problem. I'm really sorry for the inconvenience.
>>
>> Bjorn
>>
>>
>> Revert "EISA: Log device resources in dmesg"
>>
>> From: Bjorn Helgaas
>>
>> This reverts commit a2080d0c561c546d73cb8b296d4b7ca414e6860b.
>>
>> Signed-off-by: Bjorn Helgaas
>> ---
>> drivers/eisa/eisa-bus.c |1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
>> index 8842cde69177..1b86fe0c2e80 100644
>> --- a/drivers/eisa/eisa-bus.c
>> +++ b/drivers/eisa/eisa-bus.c
>> @@ -288,7 +288,6 @@ static int __init eisa_request_resources(struct
>> eisa_root_device *root,
>> edev->res[i].flags = IORESOURCE_IO | IORESOURCE_BUSY;
>> }
>>
>> - dev_printk(KERN_DEBUG, >dev, "%pR\n", >res[i]);
>> if (request_resource(root->res, >res[i]))
>> goto failed;
>> }
>> Revert "EISA: Initialize device before its resources"
>>
>> From: Bjorn Helgaas
>>
>> This reverts commit 26abfeed4341872364386c6a52b9acef8c81a81a.
>>
>> In the eisa_probe() force_probe path, if we were unable to request slot
>> resources (e.g., [io 0x800-0x8ff]), we skipped the slot with "Cannot
>> allocate resource for EISA slot %d" before reading the EISA signature in
>> eisa_init_device().
>>
>> Commit 26abfeed4341 moved eisa_init_device() earlier, so we tried to read
>> the EISA signature before requesting the slot resources, and this caused
>> hangs during boot.
>>
>> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1251816
>> Signed-off-by: Bjorn Helgaas
>> ---
>> drivers/eisa/eisa-bus.c | 26 +++---
>> 1 file changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
>> index 1b86fe0c2e80..612afeaec3cb 100644
>> --- a/drivers/eisa/eisa-bus.c
>> +++ b/drivers/eisa/eisa-bus.c
>> @@ -277,11 +277,13 @@ static int __init eisa_request_resources(struct
>> eisa_root_device *root,
>> }
>>
>> if (slot) {
>> + edev->res[i].name = NULL;
>> edev->res[i].start = SLOT_ADDRESS(root, slot)
>>+ (i * 0x400);
>> edev->res[i].end = edev->res[i].start + 0xff;
>> edev->res[i].flags = IORESOURCE_IO;
>> } else {
>> + edev->res[i].name = NULL;
>> edev->res[i].start = SLOT_ADDRESS(root, slot)
>>+ EISA_VENDOR_ID_OFFSET;
>> edev->res[i].end = edev->res[i].start + 3;
>> @@ -327,19 +329,20 @@ static int __init eisa_probe(struct eisa_root_device
>> *root)
>> return -ENOMEM;
>> }
>>
>> - if (eisa_init_device(root, edev, 0)) {
>> + if (eisa_request_resources(root, edev, 0)) {
>> + dev_warn(root->dev,
>> + "EISA: Cannot allocate resource for mainboard\n");
>> kfree(edev);
>> if (!root->force_probe)
>> - return -ENODEV;
>> + return -EBUSY;
>> goto force_probe;
>> }
>>
>> - if (eisa_request_resources(root, edev, 0)) {
>> - dev_warn(root->dev,
>> - "EISA: Cannot allocate resource for mainboard\n");
>> + if (eisa_init_device(root, edev, 0)) {
>> + eisa_release_resources(edev);
>> kfree(edev);
>> if
