* Re: [PATCH V4] kernel, add bug_on_warn
From: Andi Kleen @ 2014-10-28 12:16 UTC (permalink / raw)
To: Prarit Bhargava
Cc: linux-kernel, Jonathan Corbet, Andrew Morton, Rusty Russell,
H. Peter Anvin, Masami Hiramatsu, Fabian Frederick, vgoyal,
isimatu.yasuaki, linux-doc, kexec, linux-api, jason.wessel
In-Reply-To: <1414155207-29839-1-git-send-email-prarit@redhat.com>
On Fri, Oct 24, 2014 at 08:53:27AM -0400, Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a remote admin) it is not trivial to send new images to the
> user.
>
> A much easier method would be a switch to change the WARN() over to a
> BUG(). This makes debugging easier in that I can now test the actual
> image the WARN() was seen on and I do not have to engage in remote
> debugging.
IMHO this would be better and far more generically done with kdb.
You would need two things:
- Extend the break point command to run another command on a break point.
- Add a command line (or possibly /proc) option to execute some kdb commands at
kernel boot.
Then just set a break point on the warn function and execute magic sysrq c
from kdb.
-Andi
^ permalink raw reply
* Re: [PATCH v2 4/5] power: max77693: Add charger driver for Maxim 77693
From: Krzysztof Kozlowski @ 2014-10-28 9:16 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov, David Woodhouse,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz, Lee Jones,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kyungmin Park,
Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20141027185656.GB18965-SfvFxonMDyemK9LvCR3Hrw@public.gmane.org>
On pon, 2014-10-27 at 19:56 +0100, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Oct 20, 2014 at 02:34:48PM +0200, Krzysztof Kozlowski wrote:
> > Add new driver for Maxim 77693 switch-mode charger (part of max77693
> > MFD driver) providing power supply class information to userspace.
> >
> > The charger has +20V tolerant input. Current input can be set from 0 to
> > 2.58 A. The charger can deliver up to 2.1 A to the battery or 3.5 A to
> > the system (when supplying additional current from battery to system).
> >
> > The driver is configured through DTS (battery and system related
> > settings) and sysfs entries (timers and top-off charging threshold).
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> I guess it makes sense to queue this together with the mfd parts.
>
> Acked-By: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thank you. Could you also look at documentation change, patch 5/5:
Documentation: charger: max77693: Document exported sysfs entry
https://lkml.org/lkml/2014/10/20/232
I think that one also needs your ack as this is power supply related
ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Re: [PATCH V4] kernel, add bug_on_warn
From: Masami Hiramatsu @ 2014-10-28 5:41 UTC (permalink / raw)
To: Prarit Bhargava
Cc: Jason Baron, linux-kernel, Jonathan Corbet, Andrew Morton,
Rusty Russell, H. Peter Anvin, Andi Kleen, Fabian Frederick,
vgoyal, isimatu.yasuaki, linux-doc, kexec, linux-api
In-Reply-To: <544E8BB8.8000707@redhat.com>
(2014/10/28 3:15), Prarit Bhargava wrote:
>
>
> On 10/27/2014 02:05 PM, Jason Baron wrote:
>> Hi Prarit,
>>
>> On 10/24/2014 08:53 AM, Prarit Bhargava wrote:
>>> There have been several times where I have had to rebuild a kernel to
>>> cause a panic when hitting a WARN() in the code in order to get a crash
>>> dump from a system. Sometimes this is easy to do, other times (such as
>>> in the case of a remote admin) it is not trivial to send new images to the
>>> user.panic_on_stackoverflow
>>>
>>> A much easier method would be a switch to change the WARN() over to a
>>> BUG(). This makes debugging easier in that I can now test the actual
>>> image the WARN() was seen on and I do not have to engage in remote
>>> debugging.
>>>
>>> This patch adds a bug_on_warn kernel parameter and
>>> /proc/sys/kernel/bug_on_warn calls BUG() in the warn_slowpath_common()
>>> path. The function will still print out the location of the warning.
>>>
>>> An example of the bug_on_warn output:
>>>
>>> The first line below is from the WARN_ON() to output the WARN_ON()'s location.
>>> After that the new BUG() call is displayed.
>>>
>>> WARNING: CPU: 27 PID: 3204 at
>>> /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30
>>> [dummy_module]()
>>> bug_on_warn set, calling BUG()...
>>> ------------[ cut here ]------------
>>> kernel BUG at kernel/panic.c:434!
>>
>> Seems reasonable-I'm wondering why you just don't call panic() in this
>> case. The BUG() call at line '434' doesn't at anything since its just being
>> called from panic.c.
+1, I like calling panic() instead of BUG() :)
Thank you,
>
> Hmm ... I didn't even think about that.
>
>>
>> So something like 'panic_on_warn' would seem to be more appropriate
>> in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'.
>
> I like it a lot better that way too :) I'm changing it to panic_on_warn unless
> anyone has any strenuous objections.
>
> P.
>
>>
>> Thanks,
>>
>> -Jason
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo
From: Greg Hackmann @ 2014-10-28 4:43 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, catalin.marinas, ijc, Serban Constantinescu,
will.deacon, cross-distro, linux-api, linux-kernel
In-Reply-To: <1414159000-27059-1-git-send-email-mark.rutland@arm.com>
On Fri, Oct 24, 2014 at 6:56 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> [c] Print different hwcaps for compat tasks
>
> This would allow for 32-bit and 64-bit applications to function
> correctly. Having the format differ depending on the instruction set
> of the application reading /proc/cpuinfo may be misleading in some
> cases (e.g. a human using a 32-bit cat to read /proc/cpuinfo on a
> 64-bit system).
FWIW we have an Nvidia-contributed patch in the android-3.10 kernel
tree that basically does this. It works well in almost all cases.
We've only found one situation so far where this approach falls apart.
One specific Android NDK app detects NEON support by running
"/system/bin/cat /proc/cpuinfo" in another process and searching for
the string "neon" in the output. Even though the app itself is
32-bit, /system/bin/cat is 64-bit, so it reads the "wrong"
/proc/cpuinfo and decides the CPU doesn't support NEON.
>From Android's perspective, the only downside of using personalities
instead is that our runtime will need to ensure 32-bit apps have the
right personality. Our runtime team has said they're fine with doing
this, if that's the direction the upstream kernel wants to go.
> Are there applications for which any of these strategies will not work?
We've found a handful of Android apps that expect the "CPU
architecture" field to be "7" specifically and get confused by the
existence of ARMv8. There's not much you can do on the kernel side to
support those apps, other than lying about the CPU architecture to
32-bit apps (and we drew the line at doing that).
^ permalink raw reply
* Re: [PATCH V4] kernel, add bug_on_warn
From: Dave Young @ 2014-10-28 2:32 UTC (permalink / raw)
To: Prarit Bhargava
Cc: Jason Baron, Andi Kleen, Jonathan Corbet, kexec, Rusty Russell,
linux-doc, linux-kernel, Fabian Frederick, isimatu.yasuaki,
H. Peter Anvin, Masami Hiramatsu, Andrew Morton, linux-api,
vgoyal
In-Reply-To: <544E8BB8.8000707@redhat.com>
> > Seems reasonable-I'm wondering why you just don't call panic() in this
> > case. The BUG() call at line '434' doesn't at anything since its just being
> > called from panic.c.
>
> Hmm ... I didn't even think about that.
>
> >
> > So something like 'panic_on_warn' would seem to be more appropriate
> > in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'.
>
> I like it a lot better that way too :) I'm changing it to panic_on_warn unless
> anyone has any strenuous objections.
I would vote for panic_on_warn, it will make more sense than bug_on_warn.
Thanks
Dave
^ permalink raw reply
* Re: [PATCH V4] kernel, add bug_on_warn
From: Yasuaki Ishimatsu @ 2014-10-28 0:00 UTC (permalink / raw)
To: Prarit Bhargava
Cc: linux-kernel, Jonathan Corbet, Andrew Morton, Rusty Russell,
H. Peter Anvin, Andi Kleen, Masami Hiramatsu, Fabian Frederick,
vgoyal, linux-doc, kexec, linux-api
In-Reply-To: <1414155207-29839-1-git-send-email-prarit@redhat.com>
(2014/10/24 21:53), Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a remote admin) it is not trivial to send new images to the
> user.
>
> A much easier method would be a switch to change the WARN() over to a
> BUG(). This makes debugging easier in that I can now test the actual
> image the WARN() was seen on and I do not have to engage in remote
> debugging.
>
> This patch adds a bug_on_warn kernel parameter and
> /proc/sys/kernel/bug_on_warn calls BUG() in the warn_slowpath_common()
> path. The function will still print out the location of the warning.
>
> An example of the bug_on_warn output:
>
> The first line below is from the WARN_ON() to output the WARN_ON()'s location.
> After that the new BUG() call is displayed.
>
> WARNING: CPU: 27 PID: 3204 at
> /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30
> [dummy_module]()
> bug_on_warn set, calling BUG()...
> ------------[ cut here ]------------
> kernel BUG at kernel/panic.c:434!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: dummy_module(OE+) sg nfsv3 rpcsec_gss_krb5 nfsv4
> dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal intel_powerclamp
> coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel igb iTCO_wdt aesni_intel iTCO_vendor_support lrw gf128mul
> sb_edac ptp edac_core glue_helper lpc_ich ioatdma pcspkr ablk_helper pps_core
> i2c_i801 mfd_core cryptd dca shpchp ipmi_si wmi ipmi_msghandler acpi_cpufreq
> nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c sr_mod cdrom sd_mod
> mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper isci ttm
> drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror
> dm_region_hash dm_log dm_mod
> CPU: 27 PID: 3204 Comm: insmod Tainted: G OE 3.17.0+ #19
> Hardware name: Intel Corporation S2600CP/S2600CP, BIOS
> RMLSDP.86I.00.29.D696.1311111329 11/11/2013
> task: ffff880034e75160 ti: ffff8807fc5ac000 task.ti: ffff8807fc5ac000
> RIP: 0010:[<ffffffff81076b81>] [<ffffffff81076b81>] warn_slowpath_common+0xc1/0xd0
> RSP: 0018:ffff8807fc5afc68 EFLAGS: 00010246
> RAX: 0000000000000021 RBX: ffff8807fc5afcb0 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff88081efee5f8 RDI: ffff88081efee5f8
> RBP: ffff8807fc5afc98 R08: 0000000000000096 R09: 0000000000000000
> R10: 0000000000000711 R11: ffff8807fc5af93e R12: ffffffffa0424070
> R13: 0000000000000019 R14: ffffffffa0423068 R15: 0000000000000009
> FS: 00007f2d4b034740(0000) GS:ffff88081efe0000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f2d4a99f3c0 CR3: 00000007fd88b000 CR4: 00000000001407e0
> Stack:
> ffff8807fc5afcb8 ffffffff8199f020 ffff88080e396160 0000000000000000
> ffffffffa0423040 ffffffffa0425000 ffff8807fc5afd08 ffffffff81076be5
> 0000000000000008 ffffffffa0424053 ffff880700000018 ffff8807fc5afd18
> Call Trace:
> [<ffffffffa0423040>] ? dummy_greetings+0x40/0x40 [dummy_module]
> [<ffffffff81076be5>] warn_slowpath_fmt+0x55/0x70
> [<ffffffffa0423068>] init_dummy+0x28/0x30 [dummy_module]
> [<ffffffff81002144>] do_one_initcall+0xd4/0x210
> [<ffffffff811b52c2>] ? __vunmap+0xc2/0x110
> [<ffffffff810f8889>] load_module+0x16a9/0x1b30
> [<ffffffff810f3d30>] ? store_uevent+0x70/0x70
> [<ffffffff810f49b9>] ? copy_module_from_fd.isra.44+0x129/0x180
> [<ffffffff810f8ec6>] SyS_finit_module+0xa6/0xd0
> [<ffffffff8166ce29>] system_call_fastpath+0x12/0x17
> Code: c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 c7 c7 20 42 8a 81 31 c0 e8 fc
> 80 5e 00 eb 80 48 c7 c7 78 42 8a 81 31 c0 e8 ec 80 5e 00 <0f> 0b 66 66 66 66 2e
> 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55
> RIP [<ffffffff81076b81>] warn_slowpath_common+0xc1/0xd0
> RSP <ffff8807fc5afc68>
> ---[ end trace 428218934a12088b ]---
>
> Successfully tested by me.
>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Fabian Frederick <fabf@skynet.be>
> Cc: vgoyal@redhat.com
> Cc: isimatu.yasuaki@jp.fujitsu.com
> Cc: linux-doc@vger.kernel.org
> Cc: kexec@lists.infradead.org
> Cc: linux-api@vger.kernel.org
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>
> [v2]: add /proc/sys/kernel/bug_on_warn, additional documentation, modify
> !slowpath cases
> [v3]: use proc_dointvec_minmax() in sysctl handler
> [v4]: remove !slowpath cases, and add __read_mostly
> ---
Looks good to me.
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Thanks,
Yasuaki Ishimatsu
> Documentation/kdump/kdump.txt | 7 +++++++
> Documentation/kernel-parameters.txt | 3 +++
> Documentation/sysctl/kernel.txt | 12 ++++++++++++
> include/linux/kernel.h | 1 +
> include/uapi/linux/sysctl.h | 1 +
> kernel/panic.c | 21 ++++++++++++++++++++-
> kernel/sysctl.c | 9 +++++++++
> kernel/sysctl_binary.c | 1 +
> 8 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 6c0b9f2..a04ed72 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -471,6 +471,13 @@ format. Crash is available on Dave Anderson's site at the following URL:
>
> http://people.redhat.com/~anderson/
>
> +Trigger Kdump on WARN()
> +=======================
> +
> +The kernel parameter, bug_on_warn, calls BUG() in all WARN() paths. This
> +will cause a kdump to occur at the BUG() call. In cases where a user
> +wants to specify this during runtime, /proc/sys/kernel/bug_on_warn can be
> +set to 1 to achieve the same behaviour.
>
> Contact
> =======
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 74339c5..aa1d319 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -553,6 +553,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> bttv.pll= See Documentation/video4linux/bttv/Insmod-options
> bttv.tuner=
>
> + bug_on_warn BUG() instead of WARN(). Useful to cause kdump
> + on a WARN().
> +
> bulk_remove=off [PPC] This parameter disables the use of the pSeries
> firmware feature for flushing multiple hpte entries
> at a time.
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 57baff5..dcadcdc 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -23,6 +23,7 @@ show up in /proc/sys/kernel:
> - auto_msgmni
> - bootloader_type [ X86 only ]
> - bootloader_version [ X86 only ]
> +- bug_on_warn
> - callhome [ S390 only ]
> - cap_last_cap
> - core_pattern
> @@ -152,6 +153,17 @@ Documentation/x86/boot.txt for additional information.
>
> ==============================================================
>
> +bug_on_warn:
> +
> +Calls BUG() in the WARN() path when set to 1. This is useful to avoid
> +a kernel rebuild when attempting to kdump at the location of a WARN().
> +
> +0: only WARN(), default behaviour.
> +
> +1: call BUG() after printing out WARN() location.
> +
> +==============================================================
> +
> callhome:
>
> Controls the kernel's callhome behavior in case of a kernel panic.
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 3d770f55..fc28bff 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -423,6 +423,7 @@ extern int panic_on_oops;
> extern int panic_on_unrecovered_nmi;
> extern int panic_on_io_nmi;
> extern int sysctl_panic_on_stackoverflow;
> +extern int bug_on_warn;
> /*
> * Only to be used by arch init code. If the user over-wrote the default
> * CONFIG_PANIC_TIMEOUT, honor it.
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 43aaba1..2ba0a58 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -153,6 +153,7 @@ enum
> KERN_MAX_LOCK_DEPTH=74, /* int: rtmutex's maximum lock depth */
> KERN_NMI_WATCHDOG=75, /* int: enable/disable nmi watchdog */
> KERN_PANIC_ON_NMI=76, /* int: whether we will panic on an unrecovered */
> + KERN_BUG_ON_WARN=77, /* int: call BUG() in WARN() functions */
> };
>
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index d09dc5c..740d9ff 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -33,6 +33,7 @@ static int pause_on_oops;
> static int pause_on_oops_flag;
> static DEFINE_SPINLOCK(pause_on_oops_lock);
> static bool crash_kexec_post_notifiers;
> +int bug_on_warn __read_mostly;
>
> int panic_timeout = CONFIG_PANIC_TIMEOUT;
> EXPORT_SYMBOL_GPL(panic_timeout);
> @@ -420,13 +421,24 @@ static void warn_slowpath_common(const char *file, int line, void *caller,
> {
> disable_trace_on_warning();
>
> - pr_warn("------------[ cut here ]------------\n");
> + if (!bug_on_warn)
> + pr_warn("------------[ cut here ]------------\n");
> pr_warn("WARNING: CPU: %d PID: %d at %s:%d %pS()\n",
> raw_smp_processor_id(), current->pid, file, line, caller);
>
> if (args)
> vprintk(args->fmt, args->args);
>
> + if (bug_on_warn) {
> + pr_warn("bug_on_warn set, calling BUG()...\n");
> + /*
> + * A flood of WARN()s may occur. Prevent further WARN()s
> + * from panicking the system.
> + */
> + bug_on_warn = 0;
> + BUG();
> + }
> +
> print_modules();
> dump_stack();
> print_oops_end_marker();
> @@ -501,3 +513,10 @@ static int __init oops_setup(char *s)
> return 0;
> }
> early_param("oops", oops_setup);
> +
> +static int __init bug_on_warn_setup(char *s)
> +{
> + bug_on_warn = 1;
> + return 0;
> +}
> +early_param("bug_on_warn", bug_on_warn_setup);
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 4aada6d..818cd31 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1103,6 +1103,15 @@ static struct ctl_table kern_table[] = {
> .proc_handler = proc_dointvec,
> },
> #endif
> + {
> + .procname = "bug_on_warn",
> + .data = &bug_on_warn,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = &zero,
> + .extra2 = &one,
> + },
> { }
> };
>
> diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
> index 9a4f750..28376bf 100644
> --- a/kernel/sysctl_binary.c
> +++ b/kernel/sysctl_binary.c
> @@ -137,6 +137,7 @@ static const struct bin_table bin_kern_table[] = {
> { CTL_INT, KERN_COMPAT_LOG, "compat-log" },
> { CTL_INT, KERN_MAX_LOCK_DEPTH, "max_lock_depth" },
> { CTL_INT, KERN_PANIC_ON_NMI, "panic_on_unrecovered_nmi" },
> + { CTL_INT, KERN_BUG_ON_WARN, "bug_on_warn" },
> {}
> };
>
>
^ permalink raw reply
* Re: [v5 5/5] Adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support for ext4
From: Dave Chinner @ 2014-10-27 22:40 UTC (permalink / raw)
To: Li Xi
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ext4 Developers List,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Theodore Ts'o, Andreas Dilger, Jan Kara,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org,
hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, Dmitry Monakhov
In-Reply-To: <CAPTn0cAAbfnqYgnCEESZeY8XaK=DSGB673Srn_TVYxETG89_OQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Oct 27, 2014 at 09:09:19AM +0800, Li Xi wrote:
> On Mon, Oct 27, 2014 at 5:56 AM, Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote:
> > On Sun, Oct 26, 2014 at 01:22:53PM +0800, Li Xi wrote:
> >> This patch adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR ioctl interface
> >> support for ext4. The interface is kept consistent with
> >> XFS_IOC_FSGETXATTR/XFS_IOC_FSGETXATTR.
> >
> > What you haven't mentioned is that you also changed the fsxattr
> > interface structure to add functionality and new behaviours that
> > isn't supported by XFS or existing applications that use the
> > interface.
> >
> > There is no need to modify the interface *at all* for ext4 to use
> > it. Fields that ext4 does not use can be zeroed on getxattr, and
> > ignored on setxattr - you do not need to add new fields to say what
> > fields are valid.
> Sorry, I don't want to change the interfaces either. But, the problem
> is that zero might be valid value for some fields. How can we
> distinguish an unsupported attribute and an attribute whose value
> is zero?
You don't. Userspace has no concept of what parts of the struct
fsxattr are valid or not, nor what are valid values the filesystem
will accept or reject.
> It is common case the only part of the fields are supported.
> So, for example, if we don't have valid flags, how can use space
> application tell kernel which attributes should be skipped when it
> tries to set only a part of atrributes?
It *doesn't*. Userspace requires the kernel to initialise the struct
fsxattr before it tries to modify anything, just like
fcntl(F_[GS]ETFL) and other similar "file flag change" syscall APIs.
IOWs, you have to initialise the struct fsxattr by calling
FS_IOC_FSGETXATTR before you call FS_IOC_FSSETXATTR. The
intialisation sets all the fields to the current (correct) values,
and hence when the set call is made all the fields then have the
same/correct values in them except for what the application changed.
E.g. this code from xfs_quota to clear the project ID on a given
file or directory:
if ((fd = open(path, O_RDONLY|O_NOCTTY)) == -1) {
// error handling ....
} else if (xfsctl(path, fd, XFS_IOC_FSGETXATTR, &fsx) < 0) {
// error handling ....
}
fsx.fsx_projid = 0;
fsx.fsx_xflags &= ~XFS_XFLAG_PROJINHERIT;
if (xfsctl(path, fd, XFS_IOC_FSSETXATTR, &fsx) < 0) {
// error handling ....
}
close(fd);
This ensures that *only* the project ID and the specific project ID
inheritance flag is cleared, and none of the other inode flags or
state are modified....
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply
* Re: [PATCH 4/4] vfs: RWF_NONBLOCK flag for preadv2
From: Milosz Tanski @ 2014-10-27 19:09 UTC (permalink / raw)
To: Steve French
Cc: LKML, Christoph Hellwig, linux-fsdevel, linux-aio@kvack.org,
Mel Gorman, Volker Lendecke, Tejun Heo, Jeff Moyer,
Theodore Ts'o, Al Viro, linux-api@vger.kernel.org,
Michael Kerrisk
In-Reply-To: <CAH2r5msUXQn+J3hoU-66Oz5EQpB7f_ObOaw9vnqY8=tgCB4J7g@mail.gmail.com>
On Mon, Oct 27, 2014 at 3:03 PM, Steve French <smfrench@gmail.com> wrote:
> What would be required for a network file system to support the
> RWF_NONBLOCK flag?
>
> SMB3 operations are all async (on the wire) by default but they do
> block on the network send and interim response.
Steve,
Any kernel filesystem that stores data in the page cache and does not
require a blocking/waiting operation (on network or diskIO, not locks)
should support this flag. If the data is in the page cache locally
we'll return it right away without blocking, otherwise we'll return
EAGAIN.
Think of this operation as being analogous to doing a recv with
MSG_NOWAIT ... where it will return data if there's data in the socket
buffer, otherwise returns EAGAIN.
I Hope this helps.
>
> On Tue, Oct 21, 2014 at 3:46 PM, Milosz Tanski <milosz@adfin.com> wrote:
>> Filesystems that generic_file_read_iter will not be allowed to perform
>> non-blocking reads. This only will read data if it's in the page cache and if
>> there is no page error (causing a re-read).
>>
>> Christoph Hellwig wrote the filesystem specify code (cifs, ofs, shm, xfs).
>>
>> Signed-off-by: Milosz Tanski <milosz@adfin.com>
>> ---
>> fs/cifs/file.c | 6 ++++++
>> fs/ocfs2/file.c | 6 ++++++
>> fs/pipe.c | 3 ++-
>> fs/read_write.c | 21 ++++++++++++++-------
>> fs/xfs/xfs_file.c | 4 ++++
>> include/linux/fs.h | 3 +++
>> mm/filemap.c | 18 ++++++++++++++++++
>> mm/shmem.c | 4 ++++
>> 8 files changed, 57 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
>> index 3e4d00a..c485afa 100644
>> --- a/fs/cifs/file.c
>> +++ b/fs/cifs/file.c
>> @@ -3005,6 +3005,9 @@ ssize_t cifs_user_readv(struct kiocb *iocb, struct iov_iter *to)
>> struct cifs_readdata *rdata, *tmp;
>> struct list_head rdata_list;
>>
>> + if (iocb->ki_rwflags & RWF_NONBLOCK)
>> + return -EAGAIN;
>> +
>> len = iov_iter_count(to);
>> if (!len)
>> return 0;
>> @@ -3123,6 +3126,9 @@ cifs_strict_readv(struct kiocb *iocb, struct iov_iter *to)
>> ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOPOSIXBRL) == 0))
>> return generic_file_read_iter(iocb, to);
>>
>> + if (iocb->ki_rwflags & RWF_NONBLOCK)
>> + return -EAGAIN;
>> +
>> /*
>> * We need to hold the sem to be sure nobody modifies lock list
>> * with a brlock that prevents reading.
>> diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
>> index 324dc93..bb66ca4 100644
>> --- a/fs/ocfs2/file.c
>> +++ b/fs/ocfs2/file.c
>> @@ -2472,6 +2472,12 @@ static ssize_t ocfs2_file_read_iter(struct kiocb *iocb,
>> filp->f_path.dentry->d_name.name,
>> to->nr_segs); /* GRRRRR */
>>
>> + /*
>> + * No non-blocking reads for ocfs2 for now. Might be doable with
>> + * non-blocking cluster lock helpers.
>> + */
>> + if (iocb->ki_rwflags & RWF_NONBLOCK)
>> + return -EAGAIN;
>>
>> if (!inode) {
>> ret = -EINVAL;
>> diff --git a/fs/pipe.c b/fs/pipe.c
>> index 21981e5..212bf68 100644
>> --- a/fs/pipe.c
>> +++ b/fs/pipe.c
>> @@ -302,7 +302,8 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
>> */
>> if (ret)
>> break;
>> - if (filp->f_flags & O_NONBLOCK) {
>> + if ((filp->f_flags & O_NONBLOCK) ||
>> + (iocb->ki_rwflags & RWF_NONBLOCK)) {
>> ret = -EAGAIN;
>> break;
>> }
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index e3d8451..955d829 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -835,14 +835,19 @@ static ssize_t do_readv_writev(int type, struct file *file,
>> file_start_write(file);
>> }
>>
>> - if (iter_fn)
>> + if (iter_fn) {
>> ret = do_iter_readv_writev(file, type, iov, nr_segs, tot_len,
>> pos, iter_fn, flags);
>> - else if (fnv)
>> - ret = do_sync_readv_writev(file, iov, nr_segs, tot_len,
>> - pos, fnv);
>> - else
>> - ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
>> + } else {
>> + if (type == READ && (flags & RWF_NONBLOCK))
>> + return -EAGAIN;
>> +
>> + if (fnv)
>> + ret = do_sync_readv_writev(file, iov, nr_segs, tot_len,
>> + pos, fnv);
>> + else
>> + ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
>> + }
>>
>> if (type != READ)
>> file_end_write(file);
>> @@ -866,8 +871,10 @@ ssize_t vfs_readv(struct file *file, const struct iovec __user *vec,
>> return -EBADF;
>> if (!(file->f_mode & FMODE_CAN_READ))
>> return -EINVAL;
>> - if (flags & ~0)
>> + if (flags & ~RWF_NONBLOCK)
>> return -EINVAL;
>> + if ((file->f_flags & O_DIRECT) && (flags & RWF_NONBLOCK))
>> + return -EAGAIN;
>>
>> return do_readv_writev(READ, file, vec, vlen, pos, flags);
>> }
>> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
>> index eb596b4..b1f6334 100644
>> --- a/fs/xfs/xfs_file.c
>> +++ b/fs/xfs/xfs_file.c
>> @@ -246,6 +246,10 @@ xfs_file_read_iter(
>>
>> XFS_STATS_INC(xs_read_calls);
>>
>> + /* XXX: need a non-blocking iolock helper, shouldn't be too hard */
>> + if (iocb->ki_rwflags & RWF_NONBLOCK)
>> + return -EAGAIN;
>> +
>> if (unlikely(file->f_flags & O_DIRECT))
>> ioflags |= XFS_IO_ISDIRECT;
>> if (file->f_mode & FMODE_NOCMTIME)
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 9ed5711..eaebd99 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1459,6 +1459,9 @@ struct block_device_operations;
>> #define HAVE_COMPAT_IOCTL 1
>> #define HAVE_UNLOCKED_IOCTL 1
>>
>> +/* These flags are used for the readv/writev syscalls with flags. */
>> +#define RWF_NONBLOCK 0x00000001
>> +
>> struct iov_iter;
>>
>> struct file_operations {
>> diff --git a/mm/filemap.c b/mm/filemap.c
>> index 45964c8..e73ba7e 100644
>> --- a/mm/filemap.c
>> +++ b/mm/filemap.c
>> @@ -1493,6 +1493,8 @@ static ssize_t do_generic_file_read(struct file *filp, loff_t *ppos,
>> find_page:
>> page = find_get_page(mapping, index);
>> if (!page) {
>> + if (flags & RWF_NONBLOCK)
>> + goto would_block;
>> page_cache_sync_readahead(mapping,
>> ra, filp,
>> index, last_index - index);
>> @@ -1584,6 +1586,11 @@ page_ok:
>> continue;
>>
>> page_not_up_to_date:
>> + if (flags & RWF_NONBLOCK) {
>> + page_cache_release(page);
>> + goto would_block;
>> + }
>> +
>> /* Get exclusive access to the page ... */
>> error = lock_page_killable(page);
>> if (unlikely(error))
>> @@ -1603,6 +1610,12 @@ page_not_up_to_date_locked:
>> goto page_ok;
>> }
>>
>> + if (flags & RWF_NONBLOCK) {
>> + unlock_page(page);
>> + page_cache_release(page);
>> + goto would_block;
>> + }
>> +
>> readpage:
>> /*
>> * A previous I/O error may have been due to temporary
>> @@ -1673,6 +1686,8 @@ no_cached_page:
>> goto readpage;
>> }
>>
>> +would_block:
>> + error = -EAGAIN;
>> out:
>> ra->prev_pos = prev_index;
>> ra->prev_pos <<= PAGE_CACHE_SHIFT;
>> @@ -1706,6 +1721,9 @@ generic_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
>> size_t count = iov_iter_count(iter);
>> loff_t size;
>>
>> + if (iocb->ki_rwflags & RWF_NONBLOCK)
>> + return -EAGAIN;
>> +
>> if (!count)
>> goto out; /* skip atime */
>> size = i_size_read(inode);
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index cd6fc75..5c30f04 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -1531,6 +1531,10 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
>> ssize_t retval = 0;
>> loff_t *ppos = &iocb->ki_pos;
>>
>> + /* XXX: should be easily supportable */
>> + if (iocb->ki_rwflags & RWF_NONBLOCK)
>> + return -EAGAIN;
>> +
>> /*
>> * Might this read be for a stacking filesystem? Then when reading
>> * holes of a sparse file, we actually need to allocate those pages,
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks,
>
> Steve
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: milosz@adfin.com
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 4/4] vfs: RWF_NONBLOCK flag for preadv2
From: Steve French @ 2014-10-27 19:03 UTC (permalink / raw)
To: Milosz Tanski
Cc: LKML, Christoph Hellwig, linux-fsdevel, linux-aio, Mel Gorman,
Volker Lendecke, Tejun Heo, Jeff Moyer, Theodore Ts'o,
Al Viro, linux-api@vger.kernel.org, Michael Kerrisk
In-Reply-To: <ba8d704a12c7ceffce610fc438a0af11a3422002.1413923420.git.milosz@adfin.com>
What would be required for a network file system to support the
RWF_NONBLOCK flag?
SMB3 operations are all async (on the wire) by default but they do
block on the network send and interim response.
On Tue, Oct 21, 2014 at 3:46 PM, Milosz Tanski <milosz@adfin.com> wrote:
> Filesystems that generic_file_read_iter will not be allowed to perform
> non-blocking reads. This only will read data if it's in the page cache and if
> there is no page error (causing a re-read).
>
> Christoph Hellwig wrote the filesystem specify code (cifs, ofs, shm, xfs).
>
> Signed-off-by: Milosz Tanski <milosz@adfin.com>
> ---
> fs/cifs/file.c | 6 ++++++
> fs/ocfs2/file.c | 6 ++++++
> fs/pipe.c | 3 ++-
> fs/read_write.c | 21 ++++++++++++++-------
> fs/xfs/xfs_file.c | 4 ++++
> include/linux/fs.h | 3 +++
> mm/filemap.c | 18 ++++++++++++++++++
> mm/shmem.c | 4 ++++
> 8 files changed, 57 insertions(+), 8 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 3e4d00a..c485afa 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -3005,6 +3005,9 @@ ssize_t cifs_user_readv(struct kiocb *iocb, struct iov_iter *to)
> struct cifs_readdata *rdata, *tmp;
> struct list_head rdata_list;
>
> + if (iocb->ki_rwflags & RWF_NONBLOCK)
> + return -EAGAIN;
> +
> len = iov_iter_count(to);
> if (!len)
> return 0;
> @@ -3123,6 +3126,9 @@ cifs_strict_readv(struct kiocb *iocb, struct iov_iter *to)
> ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NOPOSIXBRL) == 0))
> return generic_file_read_iter(iocb, to);
>
> + if (iocb->ki_rwflags & RWF_NONBLOCK)
> + return -EAGAIN;
> +
> /*
> * We need to hold the sem to be sure nobody modifies lock list
> * with a brlock that prevents reading.
> diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
> index 324dc93..bb66ca4 100644
> --- a/fs/ocfs2/file.c
> +++ b/fs/ocfs2/file.c
> @@ -2472,6 +2472,12 @@ static ssize_t ocfs2_file_read_iter(struct kiocb *iocb,
> filp->f_path.dentry->d_name.name,
> to->nr_segs); /* GRRRRR */
>
> + /*
> + * No non-blocking reads for ocfs2 for now. Might be doable with
> + * non-blocking cluster lock helpers.
> + */
> + if (iocb->ki_rwflags & RWF_NONBLOCK)
> + return -EAGAIN;
>
> if (!inode) {
> ret = -EINVAL;
> diff --git a/fs/pipe.c b/fs/pipe.c
> index 21981e5..212bf68 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -302,7 +302,8 @@ pipe_read(struct kiocb *iocb, struct iov_iter *to)
> */
> if (ret)
> break;
> - if (filp->f_flags & O_NONBLOCK) {
> + if ((filp->f_flags & O_NONBLOCK) ||
> + (iocb->ki_rwflags & RWF_NONBLOCK)) {
> ret = -EAGAIN;
> break;
> }
> diff --git a/fs/read_write.c b/fs/read_write.c
> index e3d8451..955d829 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -835,14 +835,19 @@ static ssize_t do_readv_writev(int type, struct file *file,
> file_start_write(file);
> }
>
> - if (iter_fn)
> + if (iter_fn) {
> ret = do_iter_readv_writev(file, type, iov, nr_segs, tot_len,
> pos, iter_fn, flags);
> - else if (fnv)
> - ret = do_sync_readv_writev(file, iov, nr_segs, tot_len,
> - pos, fnv);
> - else
> - ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
> + } else {
> + if (type == READ && (flags & RWF_NONBLOCK))
> + return -EAGAIN;
> +
> + if (fnv)
> + ret = do_sync_readv_writev(file, iov, nr_segs, tot_len,
> + pos, fnv);
> + else
> + ret = do_loop_readv_writev(file, iov, nr_segs, pos, fn);
> + }
>
> if (type != READ)
> file_end_write(file);
> @@ -866,8 +871,10 @@ ssize_t vfs_readv(struct file *file, const struct iovec __user *vec,
> return -EBADF;
> if (!(file->f_mode & FMODE_CAN_READ))
> return -EINVAL;
> - if (flags & ~0)
> + if (flags & ~RWF_NONBLOCK)
> return -EINVAL;
> + if ((file->f_flags & O_DIRECT) && (flags & RWF_NONBLOCK))
> + return -EAGAIN;
>
> return do_readv_writev(READ, file, vec, vlen, pos, flags);
> }
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index eb596b4..b1f6334 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -246,6 +246,10 @@ xfs_file_read_iter(
>
> XFS_STATS_INC(xs_read_calls);
>
> + /* XXX: need a non-blocking iolock helper, shouldn't be too hard */
> + if (iocb->ki_rwflags & RWF_NONBLOCK)
> + return -EAGAIN;
> +
> if (unlikely(file->f_flags & O_DIRECT))
> ioflags |= XFS_IO_ISDIRECT;
> if (file->f_mode & FMODE_NOCMTIME)
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 9ed5711..eaebd99 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1459,6 +1459,9 @@ struct block_device_operations;
> #define HAVE_COMPAT_IOCTL 1
> #define HAVE_UNLOCKED_IOCTL 1
>
> +/* These flags are used for the readv/writev syscalls with flags. */
> +#define RWF_NONBLOCK 0x00000001
> +
> struct iov_iter;
>
> struct file_operations {
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 45964c8..e73ba7e 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1493,6 +1493,8 @@ static ssize_t do_generic_file_read(struct file *filp, loff_t *ppos,
> find_page:
> page = find_get_page(mapping, index);
> if (!page) {
> + if (flags & RWF_NONBLOCK)
> + goto would_block;
> page_cache_sync_readahead(mapping,
> ra, filp,
> index, last_index - index);
> @@ -1584,6 +1586,11 @@ page_ok:
> continue;
>
> page_not_up_to_date:
> + if (flags & RWF_NONBLOCK) {
> + page_cache_release(page);
> + goto would_block;
> + }
> +
> /* Get exclusive access to the page ... */
> error = lock_page_killable(page);
> if (unlikely(error))
> @@ -1603,6 +1610,12 @@ page_not_up_to_date_locked:
> goto page_ok;
> }
>
> + if (flags & RWF_NONBLOCK) {
> + unlock_page(page);
> + page_cache_release(page);
> + goto would_block;
> + }
> +
> readpage:
> /*
> * A previous I/O error may have been due to temporary
> @@ -1673,6 +1686,8 @@ no_cached_page:
> goto readpage;
> }
>
> +would_block:
> + error = -EAGAIN;
> out:
> ra->prev_pos = prev_index;
> ra->prev_pos <<= PAGE_CACHE_SHIFT;
> @@ -1706,6 +1721,9 @@ generic_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
> size_t count = iov_iter_count(iter);
> loff_t size;
>
> + if (iocb->ki_rwflags & RWF_NONBLOCK)
> + return -EAGAIN;
> +
> if (!count)
> goto out; /* skip atime */
> size = i_size_read(inode);
> diff --git a/mm/shmem.c b/mm/shmem.c
> index cd6fc75..5c30f04 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1531,6 +1531,10 @@ static ssize_t shmem_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
> ssize_t retval = 0;
> loff_t *ppos = &iocb->ki_pos;
>
> + /* XXX: should be easily supportable */
> + if (iocb->ki_rwflags & RWF_NONBLOCK)
> + return -EAGAIN;
> +
> /*
> * Might this read be for a stacking filesystem? Then when reading
> * holes of a sparse file, we actually need to allocate those pages,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
Steve
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH v2 4/5] power: max77693: Add charger driver for Maxim 77693
From: Sebastian Reichel @ 2014-10-27 18:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Eremin-Solenikov, David Woodhouse, linux-kernel, linux-pm,
Samuel Ortiz, Lee Jones, linux-api, devicetree, Kyungmin Park,
Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1413808489-3524-5-git-send-email-k.kozlowski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
Hi,
On Mon, Oct 20, 2014 at 02:34:48PM +0200, Krzysztof Kozlowski wrote:
> Add new driver for Maxim 77693 switch-mode charger (part of max77693
> MFD driver) providing power supply class information to userspace.
>
> The charger has +20V tolerant input. Current input can be set from 0 to
> 2.58 A. The charger can deliver up to 2.1 A to the battery or 3.5 A to
> the system (when supplying additional current from battery to system).
>
> The driver is configured through DTS (battery and system related
> settings) and sysfs entries (timers and top-off charging threshold).
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
I guess it makes sense to queue this together with the mfd parts.
Acked-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv5 1/3] syscalls,x86: implement execveat() system call
From: Andy Lutomirski @ 2014-10-27 18:47 UTC (permalink / raw)
To: David Drysdale
Cc: Eric W. Biederman, Alexander Viro, Meredydd Luff,
linux-kernel@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Andrew Morton, Kees Cook, Arnd Bergmann, X86 ML,
linux-arch, Linux API
In-Reply-To: <CAHse=S-x6NKEn9EGFos6bS=asK-1mWCr0r9aji2a97_fgxU+Sg@mail.gmail.com>
On Mon, Oct 27, 2014 at 11:03 AM, David Drysdale <drysdale@google.com> wrote:
> On Wed, Oct 22, 2014 at 7:44 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, Oct 22, 2014 at 4:44 AM, David Drysdale <drysdale@google.com> wrote:
>>> Add a new system execveat(2) syscall. execveat() is to execve() as
>>> openat() is to open(): it takes a file descriptor that refers to a
>>> directory, and resolves the filename relative to that.
>>>
>>
>>> bprm->file = file;
>>> - bprm->filename = bprm->interp = filename->name;
>>> + if (fd == AT_FDCWD || filename->name[0] == '/') {
>>> + bprm->filename = filename->name;
>>> + } else {
>>> + /*
>>> + * Build a pathname that reflects how we got to the file,
>>> + * either "/dev/fd/<fd>" (for an empty filename) or
>>> + * "/dev/fd/<fd>/<filename>".
>>> + */
>>> + pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY);
>>> + if (!pathbuf) {
>>> + retval = -ENOMEM;
>>> + goto out_unmark;
>>> + }
>>> + bprm->filename = pathbuf;
>>> + if (filename->name[0] == '\0')
>>> + sprintf(pathbuf, "/dev/fd/%d", fd);
>>
>> If the fd is O_CLOEXEC, then this will result in a confused child
>> process. Should we fail exec attempts like that for non-static
>> programs? (E.g. set filename to "" or something and fix up the binfmt
>> drivers to handle that?)
>
> Isn't it just scripts that get confused here (as normal executables don't
> get to see brpm->filename)?
>
> Given that we don't know which we have at this point, I'd suggest
> carrying on regardless. Or we could fall back to use the previous
> best-effort d_path() code for O_CLOEXEC fds. Thoughts?
How hard would it be to mark the bprm as not having a path for the
binary? Then we could fail later on if and when we actually need the
path.
I don't really have a strong opinion here, though. I do prefer
actually failing the execveat call over succeeding but invoking a
script interpreter than can't possibly work.
>
>>> + else
>>> + snprintf(pathbuf, PATH_MAX,
>>> + "/dev/fd/%d/%s", fd, filename->name);
>>
>> Does this need to handle the case where the result exceeds PATH_MAX?
>
> I guess we could kmalloc(strlen(filename->name) + 19) to avoid the
> possibility of failure, but that just defers the inevitable -- the interpreter
> won't be able to open the script file anyway. But it would at least then
> generate the appropriate error (ENAMETOOLONG rather than ENOENT).
Depends whether anyone cares about bprm->filename. But I think the
code should either return an error or allocate enough space.
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* [PATCH v3] gpio: lib-sysfs: Add 'wakeup' attribute
From: Soren Brinkmann @ 2014-10-27 18:30 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot
Cc: Jonathan Corbet, linux-kernel, linux-api, linux-gpio, linux-doc,
Soren Brinkmann
Add an attribute 'wakeup' to the GPIO sysfs interface which allows
marking/unmarking a GPIO as wake IRQ.
The file 'wakeup' is created in each exported GPIOs directory, if an IRQ
is associated with that GPIO and the irqchip implements set_wake().
Writing 'enabled' to that file will enable wake for that GPIO, while
writing 'disabled' will disable wake.
Reading that file will return either 'disabled' or 'enabled' depening on
the currently set flag for the GPIO's IRQ.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
---
v3:
- add documentation
v2:
- fix error path to unlock mutex before return
As additional reference, these are the email threads of the v2 and v1
submission:
https://lkml.org/lkml/2014/10/13/481
https://lkml.org/lkml/2014/9/4/496
---
Documentation/ABI/testing/sysfs-gpio | 1 +
Documentation/gpio/sysfs.txt | 8 ++++
drivers/gpio/gpiolib-sysfs.c | 77 +++++++++++++++++++++++++++++++++---
3 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-gpio b/Documentation/ABI/testing/sysfs-gpio
index 80f4c94c7bef..4cc7f4b3f724 100644
--- a/Documentation/ABI/testing/sysfs-gpio
+++ b/Documentation/ABI/testing/sysfs-gpio
@@ -20,6 +20,7 @@ Description:
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write: high, low
/edge ... r/w as: none, falling, rising, both
+ /wakeup ... r/w as: enabled, disabled
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
diff --git a/Documentation/gpio/sysfs.txt b/Documentation/gpio/sysfs.txt
index c2c3a97f8ff7..f703377d528f 100644
--- a/Documentation/gpio/sysfs.txt
+++ b/Documentation/gpio/sysfs.txt
@@ -97,6 +97,14 @@ and have the following read/write attributes:
for "rising" and "falling" edges will follow this
setting.
+ "wakeup" ... reads as either "enabled" or "disabled". Write these
+ strings to set/clear the 'wakeup' flag of the IRQ associated
+ with this GPIO. If the IRQ has the 'wakeup' flag set, it can
+ wake the system from sleep states.
+
+ This file exists only if the pin can generate interrupts and
+ the driver implements the required infrastructure.
+
GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:
diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
index 5f2150b619a7..7588b6d5ba94 100644
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -286,6 +286,58 @@ found:
static DEVICE_ATTR(edge, 0644, gpio_edge_show, gpio_edge_store);
+static ssize_t gpio_wakeup_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t status;
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ int irq = gpiod_to_irq(desc);
+ struct irq_desc *irq_desc = irq_to_desc(irq);
+
+ mutex_lock(&sysfs_lock);
+
+ if (irqd_is_wakeup_set(&irq_desc->irq_data))
+ status = sprintf(buf, "enabled\n");
+ else
+ status = sprintf(buf, "disabled\n");
+
+ mutex_unlock(&sysfs_lock);
+
+ return status;
+}
+
+static ssize_t gpio_wakeup_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ int ret;
+ unsigned int on;
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ int irq = gpiod_to_irq(desc);
+
+ mutex_lock(&sysfs_lock);
+
+ if (sysfs_streq("enabled", buf)) {
+ on = true;
+ } else if (sysfs_streq("disabled", buf)) {
+ on = false;
+ } else {
+ mutex_unlock(&sysfs_lock);
+ return -EINVAL;
+ }
+
+ ret = irq_set_irq_wake(irq, on);
+
+ mutex_unlock(&sysfs_lock);
+
+ if (ret)
+ pr_warn("%s: failed to %s wake\n", __func__,
+ on ? "enable" : "disable");
+
+ return size;
+}
+
+static DEVICE_ATTR(wakeup, 0644, gpio_wakeup_show, gpio_wakeup_store);
+
static int sysfs_set_active_low(struct gpio_desc *desc, struct device *dev,
int value)
{
@@ -526,7 +578,7 @@ static struct class gpio_class = {
int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
{
unsigned long flags;
- int status;
+ int status, irq;
const char *ioname = NULL;
struct device *dev;
int offset;
@@ -582,11 +634,24 @@ int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
goto fail_unregister_device;
}
- if (gpiod_to_irq(desc) >= 0 && (direction_may_change ||
- !test_bit(FLAG_IS_OUT, &desc->flags))) {
- status = device_create_file(dev, &dev_attr_edge);
- if (status)
- goto fail_unregister_device;
+ irq = gpiod_to_irq(desc);
+ if (irq >= 0) {
+ struct irq_desc *irq_desc = irq_to_desc(irq);
+ struct irq_chip *irqchip = irq_desc_get_chip(irq_desc);
+
+ if (direction_may_change ||
+ !test_bit(FLAG_IS_OUT, &desc->flags)) {
+ status = device_create_file(dev, &dev_attr_edge);
+ if (status)
+ goto fail_unregister_device;
+ }
+
+ if (irqchip->flags & IRQCHIP_SKIP_SET_WAKE ||
+ irqchip->irq_set_wake) {
+ status = device_create_file(dev, &dev_attr_wakeup);
+ if (status)
+ goto fail_unregister_device;
+ }
}
set_bit(FLAG_EXPORT, &desc->flags);
--
2.1.2.1.g5e69ed6
^ permalink raw reply related
* Re: [PATCH V4] kernel, add bug_on_warn
From: Prarit Bhargava @ 2014-10-27 18:15 UTC (permalink / raw)
To: Jason Baron
Cc: Andi Kleen, Jonathan Corbet,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rusty Russell,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Fabian Frederick,
isimatu.yasuaki-+CUm20s59erQFUHtdCDX3A, H. Peter Anvin,
Masami Hiramatsu, Andrew Morton, linux-api-u79uwXL29TY76Z2rM5mHXA,
vgoyal-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <544E8985.50203-JqFfY2XvxFXQT0dZR+AlfA@public.gmane.org>
On 10/27/2014 02:05 PM, Jason Baron wrote:
> Hi Prarit,
>
> On 10/24/2014 08:53 AM, Prarit Bhargava wrote:
>> There have been several times where I have had to rebuild a kernel to
>> cause a panic when hitting a WARN() in the code in order to get a crash
>> dump from a system. Sometimes this is easy to do, other times (such as
>> in the case of a remote admin) it is not trivial to send new images to the
>> user.panic_on_stackoverflow
>>
>> A much easier method would be a switch to change the WARN() over to a
>> BUG(). This makes debugging easier in that I can now test the actual
>> image the WARN() was seen on and I do not have to engage in remote
>> debugging.
>>
>> This patch adds a bug_on_warn kernel parameter and
>> /proc/sys/kernel/bug_on_warn calls BUG() in the warn_slowpath_common()
>> path. The function will still print out the location of the warning.
>>
>> An example of the bug_on_warn output:
>>
>> The first line below is from the WARN_ON() to output the WARN_ON()'s location.
>> After that the new BUG() call is displayed.
>>
>> WARNING: CPU: 27 PID: 3204 at
>> /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30
>> [dummy_module]()
>> bug_on_warn set, calling BUG()...
>> ------------[ cut here ]------------
>> kernel BUG at kernel/panic.c:434!
>
> Seems reasonable-I'm wondering why you just don't call panic() in this
> case. The BUG() call at line '434' doesn't at anything since its just being
> called from panic.c.
Hmm ... I didn't even think about that.
>
> So something like 'panic_on_warn' would seem to be more appropriate
> in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'.
I like it a lot better that way too :) I'm changing it to panic_on_warn unless
anyone has any strenuous objections.
P.
>
> Thanks,
>
> -Jason
>
^ permalink raw reply
* [PATCH v9 04/19] vfio: amba: VFIO support for AMBA devices
From: Antonios Motakis @ 2014-10-27 18:07 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1414433284-31719-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
drivers/vfio/platform/vfio_amba.c | 116 ++++++++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 117 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_amba.c
diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
new file mode 100644
index 0000000..cf61324
--- /dev/null
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/iommu.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/notifier.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
+#include <linux/vfio.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/amba/bus.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.9"
+#define DRIVER_AUTHOR "Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>"
+#define DRIVER_DESC "VFIO for AMBA devices - User Level meta-driver"
+
+/* probing devices from the AMBA bus */
+
+static struct resource *get_amba_resource(struct vfio_platform_device *vdev,
+ int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+
+ if (i == 0)
+ return &adev->res;
+
+ return NULL;
+}
+
+static int get_amba_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+
+ if (i < AMBA_NR_IRQS)
+ return adev->irq[i];
+
+ return 0;
+}
+
+static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+{
+
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->opaque = (void *) adev;
+ vdev->name = "vfio-amba-dev";
+ vdev->flags = VFIO_DEVICE_FLAGS_AMBA;
+ vdev->get_resource = get_amba_resource;
+ vdev->get_irq = get_amba_irq;
+
+ ret = vfio_platform_probe_common(vdev, &adev->dev);
+ if (ret)
+ kfree(vdev);
+
+ return ret;
+}
+
+static int vfio_amba_remove(struct amba_device *adev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&adev->dev);
+ if(vdev) {
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct amba_id pl330_ids[] = {
+ { 0, 0 },
+};
+
+MODULE_DEVICE_TABLE(amba, pl330_ids);
+
+static struct amba_driver vfio_amba_driver = {
+ .probe = vfio_amba_probe,
+ .remove = vfio_amba_remove,
+ .id_table = pl330_ids,
+ .drv = {
+ .name = "vfio-amba",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_amba_driver(vfio_amba_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 9db1056..92469e0 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -158,6 +158,7 @@ struct vfio_device_info {
#define VFIO_DEVICE_FLAGS_RESET (1 << 0) /* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1) /* vfio-pci device */
#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
+#define VFIO_DEVICE_FLAGS_AMBA (1 << 3) /* vfio-amba device */
__u32 num_regions; /* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.1.1
^ permalink raw reply related
* [PATCH v9 02/19] vfio: platform: probe to devices on the platform bus
From: Antonios Motakis @ 2014-10-27 18:07 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1414433284-31719-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
drivers/vfio/platform/vfio_platform.c | 114 ++++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 115 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_platform.c
diff --git a/drivers/vfio/platform/vfio_platform.c b/drivers/vfio/platform/vfio_platform.c
new file mode 100644
index 0000000..3885122
--- /dev/null
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/eventfd.h>
+#include <linux/interrupt.h>
+#include <linux/iommu.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/notifier.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/uaccess.h>
+#include <linux/vfio.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/irq.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.9"
+#define DRIVER_AUTHOR "Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>"
+#define DRIVER_DESC "VFIO for platform devices - User Level meta-driver"
+
+/* probing devices from the linux platform bus */
+
+static struct resource *get_platform_resource(struct vfio_platform_device *vdev,
+ int num)
+{
+ struct platform_device *dev = (struct platform_device *) vdev->opaque;
+ int i;
+
+ for (i = 0; i < dev->num_resources; i++) {
+ struct resource *r = &dev->resource[i];
+
+ if (resource_type(r) & (IORESOURCE_MEM|IORESOURCE_IO)) {
+ if (!num)
+ return r;
+
+ num--;
+ }
+ }
+ return NULL;
+}
+
+static int get_platform_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct platform_device *pdev = (struct platform_device *) vdev->opaque;
+
+ return platform_get_irq(pdev, i);
+}
+
+static int vfio_platform_probe(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->opaque = (void *) pdev;
+ vdev->name = pdev->name;
+ vdev->flags = VFIO_DEVICE_FLAGS_PLATFORM;
+ vdev->get_resource = get_platform_resource;
+ vdev->get_irq = get_platform_irq;
+
+ ret = vfio_platform_probe_common(vdev, &pdev->dev);
+ if (ret)
+ kfree(vdev);
+
+ return ret;
+}
+
+static int vfio_platform_remove(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&pdev->dev);
+ if(vdev) {
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct platform_driver vfio_platform_driver = {
+ .probe = vfio_platform_probe,
+ .remove = vfio_platform_remove,
+ .driver = {
+ .name = "vfio-platform",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_platform_driver(vfio_platform_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 06d66c9..9db1056 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -157,6 +157,7 @@ struct vfio_device_info {
__u32 flags;
#define VFIO_DEVICE_FLAGS_RESET (1 << 0) /* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1) /* vfio-pci device */
+#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
__u32 num_regions; /* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.1.1
^ permalink raw reply related
* Re: [PATCH V4] kernel, add bug_on_warn
From: Jason Baron @ 2014-10-27 18:05 UTC (permalink / raw)
To: Prarit Bhargava
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
Andrew Morton, Rusty Russell, H. Peter Anvin, Andi Kleen,
Masami Hiramatsu, Fabian Frederick, vgoyal-H+wXaHxf7aLQT0dZR+AlfA,
isimatu.yasuaki-+CUm20s59erQFUHtdCDX3A,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1414155207-29839-1-git-send-email-prarit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Prarit,
On 10/24/2014 08:53 AM, Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a remote admin) it is not trivial to send new images to the
> user.panic_on_stackoverflow
>
> A much easier method would be a switch to change the WARN() over to a
> BUG(). This makes debugging easier in that I can now test the actual
> image the WARN() was seen on and I do not have to engage in remote
> debugging.
>
> This patch adds a bug_on_warn kernel parameter and
> /proc/sys/kernel/bug_on_warn calls BUG() in the warn_slowpath_common()
> path. The function will still print out the location of the warning.
>
> An example of the bug_on_warn output:
>
> The first line below is from the WARN_ON() to output the WARN_ON()'s location.
> After that the new BUG() call is displayed.
>
> WARNING: CPU: 27 PID: 3204 at
> /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30
> [dummy_module]()
> bug_on_warn set, calling BUG()...
> ------------[ cut here ]------------
> kernel BUG at kernel/panic.c:434!
Seems reasonable-I'm wondering why you just don't call panic() in this
case. The BUG() call at line '434' doesn't at anything since its just being
called from panic.c.
So something like 'panic_on_warn' would seem to be more appropriate
in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'.
Thanks,
-Jason
^ permalink raw reply
* [PATCH v2 3/6] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag
From: Antonios Motakis @ 2014-10-27 18:05 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1414433155-31600-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set on the
requested mappings. The IOMMU_NOEXEC flag needs to be available for all
the IOMMUs of the container used.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 1e39842..06d66c9 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -30,6 +30,7 @@ enum vfio_iommu_cap {
VFIO_DMA_CC_IOMMU = 4, /* IOMMU enforces DMA cache coherence
(ex. PCIe NoSnoop stripping) */
VFIO_EEH = 5, /* Check if EEH is supported */
+ VFIO_DMA_NOEXEC_IOMMU = 6,
};
/*
@@ -394,12 +395,17 @@ struct vfio_iommu_type1_info {
*
* Map process virtual addresses to IO virtual addresses using the
* provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
+ *
+ * To use the VFIO_DMA_MAP_FLAG_NOEXEC flag, the container must support the
+ * VFIO_DMA_NOEXEC_IOMMU capability. If mappings are created using this flag,
+ * any groups subsequently added to the container must support this capability.
*/
struct vfio_iommu_type1_dma_map {
__u32 argsz;
__u32 flags;
#define VFIO_DMA_MAP_FLAG_READ (1 << 0) /* readable from device */
#define VFIO_DMA_MAP_FLAG_WRITE (1 << 1) /* writable from device */
+#define VFIO_DMA_MAP_FLAG_NOEXEC (1 << 2) /* not executable from device */
__u64 vaddr; /* Process virtual address */
__u64 iova; /* IO virtual address */
__u64 size; /* Size of mapping (bytes) */
--
2.1.1
^ permalink raw reply related
* [PATCH v2 1/6] vfio: implement iommu driver capabilities with an enum
From: Antonios Motakis @ 2014-10-27 18:05 UTC (permalink / raw)
To: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA
Cc: open list:VFIO DRIVER, eric.auger-QSEj5FYQhm4dnm+yROfE0A,
marc.zyngier-5wv7dgnIgG8, open list:ABI/API,
will.deacon-5wv7dgnIgG8, open list, Antonios Motakis,
tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1414433155-31600-1-git-send-email-a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Currently a VFIO driver's IOMMU capabilities are encoded as a series of
numerical defines. Replace this with an enum for future maintainability.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
include/uapi/linux/vfio.h | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 6612974..1e39842 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -19,19 +19,18 @@
/* Kernel & User level defines for VFIO IOCTLs. */
-/* Extensions */
-
-#define VFIO_TYPE1_IOMMU 1
-#define VFIO_SPAPR_TCE_IOMMU 2
-#define VFIO_TYPE1v2_IOMMU 3
/*
- * IOMMU enforces DMA cache coherence (ex. PCIe NoSnoop stripping). This
- * capability is subject to change as groups are added or removed.
+ * Capabilities exposed by the VFIO IOMMU driver. Some capabilities are subject
+ * to change as groups are added or removed.
*/
-#define VFIO_DMA_CC_IOMMU 4
-
-/* Check if EEH is supported */
-#define VFIO_EEH 5
+enum vfio_iommu_cap {
+ VFIO_TYPE1_IOMMU = 1,
+ VFIO_SPAPR_TCE_IOMMU = 2,
+ VFIO_TYPE1v2_IOMMU = 3,
+ VFIO_DMA_CC_IOMMU = 4, /* IOMMU enforces DMA cache coherence
+ (ex. PCIe NoSnoop stripping) */
+ VFIO_EEH = 5, /* Check if EEH is supported */
+};
/*
* The IOCTL interface is designed for extensibility by embedding the
--
2.1.1
^ permalink raw reply related
* Re: [PATCHv5 1/3] syscalls,x86: implement execveat() system call
From: David Drysdale @ 2014-10-27 18:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Eric W. Biederman, Alexander Viro, Meredydd Luff,
linux-kernel@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Andrew Morton, Kees Cook, Arnd Bergmann, X86 ML,
linux-arch, Linux API
In-Reply-To: <CALCETrWbj=BTDyKqtbSKteANj3J3UFZnrvWv9DMosCoEZaSoeA@mail.gmail.com>
On Wed, Oct 22, 2014 at 7:44 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Oct 22, 2014 at 4:44 AM, David Drysdale <drysdale@google.com> wrote:
>> Add a new system execveat(2) syscall. execveat() is to execve() as
>> openat() is to open(): it takes a file descriptor that refers to a
>> directory, and resolves the filename relative to that.
>>
>
>> bprm->file = file;
>> - bprm->filename = bprm->interp = filename->name;
>> + if (fd == AT_FDCWD || filename->name[0] == '/') {
>> + bprm->filename = filename->name;
>> + } else {
>> + /*
>> + * Build a pathname that reflects how we got to the file,
>> + * either "/dev/fd/<fd>" (for an empty filename) or
>> + * "/dev/fd/<fd>/<filename>".
>> + */
>> + pathbuf = kmalloc(PATH_MAX, GFP_TEMPORARY);
>> + if (!pathbuf) {
>> + retval = -ENOMEM;
>> + goto out_unmark;
>> + }
>> + bprm->filename = pathbuf;
>> + if (filename->name[0] == '\0')
>> + sprintf(pathbuf, "/dev/fd/%d", fd);
>
> If the fd is O_CLOEXEC, then this will result in a confused child
> process. Should we fail exec attempts like that for non-static
> programs? (E.g. set filename to "" or something and fix up the binfmt
> drivers to handle that?)
Isn't it just scripts that get confused here (as normal executables don't
get to see brpm->filename)?
Given that we don't know which we have at this point, I'd suggest
carrying on regardless. Or we could fall back to use the previous
best-effort d_path() code for O_CLOEXEC fds. Thoughts?
>> + else
>> + snprintf(pathbuf, PATH_MAX,
>> + "/dev/fd/%d/%s", fd, filename->name);
>
> Does this need to handle the case where the result exceeds PATH_MAX?
I guess we could kmalloc(strlen(filename->name) + 19) to avoid the
possibility of failure, but that just defers the inevitable -- the interpreter
won't be able to open the script file anyway. But it would at least then
generate the appropriate error (ENAMETOOLONG rather than ENOENT).
^ permalink raw reply
* Re: [PATCHv4 RESEND 0/3] syscalls,x86: Add execveat() system call
From: David Drysdale @ 2014-10-27 18:01 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andy Lutomirski, Alexander Viro, Meredydd Luff,
linux-kernel@vger.kernel.org, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Andrew Morton, Kees Cook, Arnd Bergmann, X86 ML,
linux-arch, Linux API
In-Reply-To: <87wq7shuk6.fsf@x220.int.ebiederm.org>
On Wed, Oct 22, 2014 at 6:40 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> David Drysdale <drysdale@google.com> writes:
>> On Tue, Oct 21, 2014 at 5:29 AM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> It is more a description of what we have done but as a magic string it
>>> is descriptive. Documetation/devices.txt documents that /dev/fd/ should
>>> exist, making it an unambiguous path. Further these days the kernel
>>> sets the device naming policy in dev, so I think we are strongly safe in
>>> using that path in any event.
>>>
>>> I think execveat is interesting in the kernel because the motivating
>>> cases are the cases where anything except a static executable is
>>> uninteresting.
>>
>> FYI, there is potential in the future for something other than static
>> executables -- the FreeBSD Capsicum implementation includes changes
>> to the dynamic linker to get its search path as a list of pre-opened dfds
>> (in LD_LIBRARY_PATH_FDS) rather than paths.
>
> Which still leaves open the question how do you find the dynamic
> linker. Is that also a pre-opened dfd?
I *think* it's still effectively a path lookup of the INTERP header in
the kernel (but the pathname is restricted to be one of a set of
standard pre-registered interpreters).
> Using /dev/fd/$N is also the kind of thing that a shell or a script
> interpret could special case instead relying on a filesystem node
> to exist.
True.
^ permalink raw reply
* Re: [PATCH 4/4] vfs: RWF_NONBLOCK flag for preadv2
From: Christoph Hellwig @ 2014-10-27 9:58 UTC (permalink / raw)
To: Milosz Tanski
Cc: Jeff Moyer, LKML, Christoph Hellwig,
linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman,
Volker Lendecke, Tejun Heo, Theodore Ts'o, Al Viro, Linux API,
Michael Kerrisk
In-Reply-To: <CANP1eJE-gRPNc9xDpAYKHVzcwS+v3AwDb=Dm1CBa=sevSczqjg@mail.gmail.com>
On Fri, Oct 24, 2014 at 01:16:04PM -0400, Milosz Tanski wrote:
> Christoph, should I apply your last 3 patches to the end of this tree
> and send it along with the next submission?
Yes, please do. Please make sure to take my fixed repost of the
"xfs: add RWF_NONBLOCK support" patch.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [v5 5/5] Adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support for ext4
From: Li Xi @ 2014-10-27 1:09 UTC (permalink / raw)
To: Dave Chinner
Cc: linux-fsdevel@vger.kernel.org, Ext4 Developers List,
linux-api@vger.kernel.org, Theodore Ts'o, Andreas Dilger,
Jan Kara, viro@zeniv.linux.org.uk, hch@infradead.org,
Dmitry Monakhov
In-Reply-To: <20141026215626.GC4317@dastard>
On Mon, Oct 27, 2014 at 5:56 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Sun, Oct 26, 2014 at 01:22:53PM +0800, Li Xi wrote:
>> This patch adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR ioctl interface
>> support for ext4. The interface is kept consistent with
>> XFS_IOC_FSGETXATTR/XFS_IOC_FSGETXATTR.
>
> What you haven't mentioned is that you also changed the fsxattr
> interface structure to add functionality and new behaviours that
> isn't supported by XFS or existing applications that use the
> interface.
>
> There is no need to modify the interface *at all* for ext4 to use
> it. Fields that ext4 does not use can be zeroed on getxattr, and
> ignored on setxattr - you do not need to add new fields to say what
> fields are valid.
Sorry, I don't want to change the interfaces either. But, the problem
is that zero might be valid value for some fields. How can we
distinguish an unsupported attribute and an attribute whose value
is zero? It is common case the only part of the fields are supported.
So, for example, if we don't have valid flags, how can use space
application tell kernel which attributes should be skipped when it
tries to set only a part of atrributes?
Regards,
Li Xi
^ permalink raw reply
* Re: [v5 4/5] Adds ioctl interface support for ext4 project
From: Dave Chinner @ 2014-10-26 21:57 UTC (permalink / raw)
To: Li Xi
Cc: linux-fsdevel, linux-ext4, linux-api, tytso, adilger, jack, viro,
hch, dmonakhov
In-Reply-To: <1414300973-1118-5-git-send-email-lixi@ddn.com>
On Sun, Oct 26, 2014 at 01:22:52PM +0800, Li Xi wrote:
> This patch adds ioctl interface for setting/getting project of ext4.
If you add support for the XFS_IOC_[GS]ETXATTR ioctls, then this
patch needs to be dropped - we don't want (or need) multiple
interfaces to perform the same functionality.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [v5 5/5] Adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support for ext4
From: Dave Chinner @ 2014-10-26 21:56 UTC (permalink / raw)
To: Li Xi
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, tytso-3s7WtUTddSA,
adilger-m1MBpc4rdrD3fQ9qLvQP4Q, jack-AlSwsSmVLrQ,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, hch-wEGCiKHe2LqWVfeAwA7xHQ,
dmonakhov-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1414300973-1118-6-git-send-email-lixi-LfVdkaOWEx8@public.gmane.org>
On Sun, Oct 26, 2014 at 01:22:53PM +0800, Li Xi wrote:
> This patch adds FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR ioctl interface
> support for ext4. The interface is kept consistent with
> XFS_IOC_FSGETXATTR/XFS_IOC_FSGETXATTR.
What you haven't mentioned is that you also changed the fsxattr
interface structure to add functionality and new behaviours that
isn't supported by XFS or existing applications that use the
interface.
There is no need to modify the interface *at all* for ext4 to use
it. Fields that ext4 does not use can be zeroed on getxattr, and
ignored on setxattr - you do not need to add new fields to say what
fields are valid.
> +/*
> + * Extend attribute flags. These should be or-ed together to figure out what
> + * is valid.
> + */
> +#define FSX_XFLAGS (1 << 0)
> +#define FSX_EXTSIZE (1 << 1)
> +#define FSX_NEXTENTS (1 << 2)
> +#define FSX_PROJID (1 << 3)
They are not interface definition flags - these are internal XFS
flags to tell an internal shared function what the caller was
modifying. I actually have a series of patches that removes them
because the internal XFS code shouldn't be shared in this way. As
such, they shouldn't be propagated into the user interface for the
ioctls....
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply
* Re: [v5 4/5] Adds ioctl interface support for ext4 project
From: Arnd Bergmann @ 2014-10-26 7:49 UTC (permalink / raw)
To: Li Xi, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, tytso-3s7WtUTddSA,
adilger-m1MBpc4rdrD3fQ9qLvQP4Q, jack-AlSwsSmVLrQ,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, hch-wEGCiKHe2LqWVfeAwA7xHQ,
dmonakhov-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <1414300973-1118-5-git-send-email-lixi-LfVdkaOWEx8@public.gmane.org>
On October 26, 2014 6:22:52 AM CET, Li Xi <pkuelelixi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> #define EXT4_IOC_PRECACHE_EXTENTS _IO('f', 18)
>+#define EXT4_IOC_GETPROJECT _IOR('f', 19, long)
>+#define EXT4_IOC_SETPROJECT _IOW('f', 20, long)
>+ projid = (__u32)from_kprojid(&init_user_ns,
>+ EXT4_I(inode)->i_projid);
>+ return put_user(projid, (__u32 __user *) arg);
>+ }
>+ case EXT4_IOC_SETPROJECT:
>+ {
>+ __u32 projid;
>+
>+ if (get_user(projid, (__u32 __user *) arg))
>+ return -EFAULT;
>+
>+ return ext4_ioctl_setproject(filp,
Types don't match. Please use __u32 in the command definition instead of long, otherwise 32 bit compact won't work.
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox