pull-request: wireless-drivers-next 2019-07-06
Hi Dave, here's a pull request to net-next tree for v5.3, more info below. I will be offline from Sunday to Thursday, but Johannes should be able to help during that time. Kalle The following changes since commit 8b89d8dad5df177032e7e97ecfb18f01134e0e4b: Merge branch 'macb-build-fixes' (2019-06-26 14:09:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-07-06 for you to fetch changes up to 5adcdab6ae1b0a53456e8a269b1856094dc20a59: Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2019-07-01 22:23:11 +0300) wireless-drivers-next patches for 5.3 Second, and last, set of patches for 5.3. Major changes: mt76 * use NAPI polling for tx cleanup on mt7603/mt7615 * add support for toggling edcca on mt7603 * fix rate control / tx status reporting issues on mt76x02/mt7603 * add support for eeprom calibration data from mtd on mt7615 * support configuring tx power on mt7615 * per-chain signal reporting on mt7615 iwlwifi * Update the FW API for Channel State Information (CSI) * Special Specific Absorption Rate (SAR) implementation for South Korea ath10k * fixes for SDIO support * add support for firmware logging via WMI Ahmad Masri (4): wil6210: enlarge Tx status ring size wil6210: increase the frequency of status ring hw tail update wil6210: set WIL_WMI_CALL_GENERAL_TO_MS as wmi_call timeout wil6210: drop old event after wmi_call timeout Alexei Avshalom Lazar (3): wil6210: do not reset FW in STA to P2P client interface switch wil6210: Add support for setting RBUFCAP configuration wil6210: update cid boundary check of wil_find_cid/_by_idx() Andrei Otcheretianski (1): iwlwifi: mvm: Drop large non sta frames Ashok Raj Nagarajan (1): ath10k: add support for controlling tx power to a station Balaji Pothunoori (1): ath10k: enabling tx stats support over pktlog Brian Norris (2): mwifiex: dispatch/rotate from reorder table atomically mwifiex: don't disable hardirqs; just softirqs Christian Lamparter (2): carl9170: fix misuse of device driver API carl9170: remove dead branch in op_conf_tx callback Christoph Hellwig (4): b43legacy: remove b43legacy_dma_set_mask b43legacy: simplify engine type / DMA mask selection b43: remove b43_dma_set_mask b43: simplify engine type / DMA mask selection Claire Chang (2): ath10k: acquire lock to fix lockdep's warning ath10k: add missing error handling Dan Carpenter (3): mt76: Fix a signedness bug in mt7615_add_interface() mt76: mt7615: Use after free in mt7615_mcu_set_bcn() iwlwifi: remove some unnecessary NULL checks Dedy Lansky (1): wil6210: fix printout in wil_read_pmccfg Dundi Raviteja (2): ath10k: Add peer delete response event ath10k: Fix memory leak in qmi Emmanuel Grumbach (7): iwlwifi: support FSEQ TLV even when FMAC is not compiled iwlwifi: mvm: make the usage of TWT configurable iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices iwlwifi: pcie: don't service an interrupt that was masked iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-Kill iwlwifi: mvm: clear rfkill_safe_init_done when we start the firmware Erik Stromdahl (2): ath10k: add inline wrapper for htt_h2t_aggr_cfg_msg ath10k: add htt_h2t_aggr_cfg_msg op for high latency devices Fabio Estevam (1): ath10k: Change the warning message string Felix Fietkau (7): mt76: mt7603: fix reading target tx power from eeprom mt76: fix setting chan->max_power mt76: mt76x02: fix tx status reporting issues mt76: mt76x02: fix tx reordering on rate control probing without a-mpdu mt76: mt76x0: fix RF frontend initialization for external PA mt76: mt7603: rework and fix tx status reporting mt76: mt7603: improve hardware rate switching configuration Govind Singh (1): ath10k: Add WMI diag fw logging support for WCN3990 Greg Kroah-Hartman (1): wil6210: no need to check return value of debugfs_create functions Gustavo A. R. Silva (2): iwlwifi: lib: Use struct_size() helper iwlwifi: d3: Use struct_size() helper Haim Dreyfuss (2): iwlwifi: Add support for SAR South Korea limitation iwlwifi: mvm: Add log information about SAR status Jiri Kosina (1): iwlwifi: iwl_mvm_tx_mpdu() must be called with BH disabled Johannes Berg (3): iwlwifi: update CSI API iwlwifi: fix module init error paths iwlwifi: mvm: delay GTK setting in FW in AP mode Kalle Valo (5): ath10k: remove unnecessary 'out of memory' message ath10k:
[GIT PULL] i3c: Changes for 5.3
Hello Linus, Here is the I3C PR for 5.3. Regards, Boris The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git tags/i3c/for-5.3 for you to fetch changes up to ede2001569c32e5bafd2203c7272bbd3249e942e: i3c: master: Use struct_size() helper (2019-07-04 12:05:14 +0200) * Drop support for 10-bit I2C addresses * Add support for limited bus mode * Fix the Cadence DT binding doc * Use struct_size() to allocate a DEFSLVS packet Gustavo A. R. Silva (1): i3c: master: Use struct_size() helper Przemyslaw Gaj (2): i3c: Drop support for I2C 10 bit addresing dt-bindings: i3c: Document dropped support for I2C 10 bit devices Qii Wang (1): dt-bindings: i3c: cdns: Use correct cells for I2C device Vitor Soares (3): i3c: fix i2c and i3c scl rate by bus mode i3c: add mixed limited bus mode i3c: dw: add limited bus mode support Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt | 2 +- Documentation/devicetree/bindings/i3c/i3c.txt | 4 +++- drivers/i3c/master.c | 82 +++--- drivers/i3c/master/dw-i3c-master.c| 7 +-- drivers/i3c/master/i3c-master-cdns.c | 10 +- include/linux/i3c/master.h| 10 ++ 6 files changed, 71 insertions(+), 44 deletions(-)
Re: [PATCH] ACPI: PM: Fix "multiple definition of acpi_sleep_state_supported" for ARM64
On Fri, Jul 5, 2019 at 10:18 PM Dexuan Cui wrote:
>
>
> If CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT is not set, the dummy version of
> the function should be static.
>
> Fixes: 1e2c3f0f1e93 ("ACPI: PM: Make acpi_sleep_state_supported() non-static")
> Signed-off-by: Dexuan Cui
> Reported-by: kbuild test robot
> ---
>
> Sorry for not doing it right in the previous patch!
>
> The patch fixes the build errors on ARM64:
>
>drivers/net/ethernet/qualcomm/emac/emac-phy.o: In function
> `acpi_sleep_state_supported':
> >> emac-phy.c:(.text+0x1d8): multiple definition of
> >> `acpi_sleep_state_supported'
>drivers/net/ethernet/qualcomm/emac/emac.o:emac.c:(.text+0xbf8): first
> defined here
>drivers/net/ethernet/qualcomm/emac/emac-sgmii.o: In function
> `acpi_sleep_state_supported':
>emac-sgmii.c:(.text+0x548): multiple definition of
> `acpi_sleep_state_supported'
>drivers/net/ethernet/qualcomm/emac/emac.o:emac.c:(.text+0xbf8): first
> defined here
>
>
> include/acpi/acpi_bus.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 4ce59bdc852e..8ffc4acf2b56 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -657,7 +657,7 @@ static inline int acpi_pm_set_bridge_wakeup(struct device
> *dev, bool enable)
> #ifdef CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT
> bool acpi_sleep_state_supported(u8 sleep_state);
> #else
> -bool acpi_sleep_state_supported(u8 sleep_state) { return false; }
> +static bool acpi_sleep_state_supported(u8 sleep_state) { return false; }
This should be static inline even.
I've reapplied the original patch with this change folded in.
Thanks!
[tip:timers/core] timer: Document TIMER_PINNED
Commit-ID: 876d00da42ecd4e985e58faa6239f7ee7e01a8b1
Gitweb: https://git.kernel.org/tip/876d00da42ecd4e985e58faa6239f7ee7e01a8b1
Author: Peter Xu
AuthorDate: Fri, 28 Jun 2019 18:59:42 +0800
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jul 2019 09:57:36 +0200
timer: Document TIMER_PINNED
The flag hints the user that the pinned timers will always be run on a
static CPU (because that should be what "pinned" means...) but that's
not the truth, at least with the current implementation.
For example, currently if a pinned timer is set up but later mod_timer()
upon the pinned timer is invoked, mod_timer() will still try to queue the
timer on the current processor and migrate the timer if necessary.
Document it a bit with the definition of TIMER_PINNED so that all future
users will use it correctly.
Signed-off-by: Peter Xu
Signed-off-by: Thomas Gleixner
Cc: Marcelo Tosatti
Cc: Luiz Capitulino
Link: https://lkml.kernel.org/r/20190628105942.14131-1-pet...@redhat.com
---
include/linux/timer.h | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/include/linux/timer.h b/include/linux/timer.h
index 7b066fd38248..282e4f2a532a 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -36,19 +36,30 @@ struct timer_list {
#define __TIMER_LOCKDEP_MAP_INITIALIZER(_kn)
#endif
-/*
- * A deferrable timer will work normally when the system is busy, but
- * will not cause a CPU to come out of idle just to service it; instead,
- * the timer will be serviced when the CPU eventually wakes up with a
- * subsequent non-deferrable timer.
+/**
+ * @TIMER_DEFERRABLE: A deferrable timer will work normally when the
+ * system is busy, but will not cause a CPU to come out of idle just
+ * to service it; instead, the timer will be serviced when the CPU
+ * eventually wakes up with a subsequent non-deferrable timer.
*
- * An irqsafe timer is executed with IRQ disabled and it's safe to wait for
- * the completion of the running instance from IRQ handlers, for example,
- * by calling del_timer_sync().
+ * @TIMER_IRQSAFE: An irqsafe timer is executed with IRQ disabled and
+ * it's safe to wait for the completion of the running instance from
+ * IRQ handlers, for example, by calling del_timer_sync().
*
* Note: The irq disabled callback execution is a special case for
* workqueue locking issues. It's not meant for executing random crap
* with interrupts disabled. Abuse is monitored!
+ *
+ * @TIMER_PINNED: A pinned timer will not be affected by any timer
+ * placement heuristics (like, NOHZ) and will always expire on the CPU
+ * on which the timer was enqueued.
+ *
+ * Note: Because enqueuing of timers can migrate the timer from one
+ * CPU to another, pinned timers are not guaranteed to stay on the
+ * initialy selected CPU. They move to the CPU on which the enqueue
+ * function is invoked via mod_timer() or add_timer(). If the timer
+ * should be placed on a particular CPU, then add_timer_on() has to be
+ * used.
*/
#define TIMER_CPUMASK 0x0003
#define TIMER_MIGRATING0x0004
[PATCH] staging: speakup: One function call less in speakup_win_enable()
From: Markus Elfring
Date: Sat, 6 Jul 2019 10:03:56 +0200
Avoid an extra function call by using a ternary operator instead of
a conditional statement.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/staging/speakup/main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 488f2539aa9a..03bbc9a4dbb3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1917,10 +1917,9 @@ static void speakup_win_enable(struct vc_data *vc)
return;
}
win_enabled ^= 1;
- if (win_enabled)
- synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCED));
- else
- synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCE_DISABLED));
+ synth_printf("%s\n", spk_msg_get(win_enabled
+? MSG_WINDOW_SILENCED
+: MSG_WINDOW_SILENCE_DISABLED));
}
static void speakup_bits(struct vc_data *vc)
--
2.22.0
Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
On Fri, Jul 5, 2019 at 7:22 PM Thomas Lindroth wrote: > > On recent kernels the tick remains active on idle adaptive-tick CPUs when a > small value is written to /dev/cpu_dma_latency to restrict the highest > C-state. Before the idle loop redesign in 4.17 idle CPUs had the tick > disabled even when C-state were restricted. Is this change intentional or a > regression? It was intentional, but this kind of is a gray area. At least for the menu governor you may argue that the decision on whether or not to stop the tick should be based on the predicted idle duration. > I use an x86_64 system built with CONFIG_NO_HZ_FULL that I recently upgraded > to the 4.19 series from the 4.14 series. I noticed that adaptive-tick CPUs > (nohz_full=1-7) still fire timer interrupts about 1000 times/s > (CONFIG_HZ_1000=y) even when they are mostly idle. Some debugging showed that > this only happens when a program is writing to /dev/cpu_dma_latency to > restrict C-states. The old 4.14 kernel only have around 10 timer interrupts > per second on idle adaptive-tick CPU even when C-states are restricted that > way. > > I would expect an adaptive-tick CPU to turn off the tick when it has 0 or 1 > processes to run and enable the tick for >2 processes. Kernels after 4.17 > instead have the tick on when 0 or >2 processes are running and the tick off > in the 1 process case. Since the tick is off when a single process is running > that workload isn't directly harmed by the change but if the CPU use > hyperthreading the constant wakeups on an idle HT sibling will reduce > performance on the other sibling. > > They way I look for timer interrupts is by comparing the LOC line in > /proc/interrupts or using the hrtimer_expire_entry tracepoint when > function=tick_sched_timer. Both methods seem to give the same results. > > I can reproduce the problem using an i7-4790K CPU with > /sys/devices/system/cpu/cpuidle/current_driver:intel_idle. I can also > reproduce the problem on an old core2duo laptop with current_driver:acpi_idle > but I can't reproduce the problem in a virtual machine where > current_driver:none. I also can't reproduce the problem if C-states are > restricted using the intel_idle.max_cstate=1 kernel argument instead of > /dev/cpu_dma_latency. > > The commit that introduced the change is 554c8aa8ec "sched: idle: Select idle > state before stopping the tick" in v4.17 and the problem exists at least up > to kernel 5.1 using the menu cpuidle governor. Restoring the previous behavior in this case should be relatively straightforward. I'll send you a patch to do that later.
Re: [PATCH] powerpc/hw_breakpoint: move instruction stepping out of hw_breakpoint_handler()
Le 03/07/2019 à 08:20, Ravi Bangoria a écrit :
On 6/28/19 9:25 PM, Christophe Leroy wrote:
On 8xx, breakpoints stop after executing the instruction, so
stepping/emulation is not needed. Move it into a sub-function and
remove the #ifdefs.
Signed-off-by: Christophe Leroy
---
Reviewed-by: Ravi Bangoria
Just one neat below...
Thanks for the review.
[...]
-#ifndef CONFIG_PPC_8xx
- /* Do not emulate user-space instructions, instead single-step them */
- if (user_mode(regs)) {
- current->thread.last_hit_ubp = bp;
- regs->msr |= MSR_SE;
+ if (!IS_ENABLED(CONFIG_PPC_8xx) && !stepping_handler(regs, bp,
info->address))
May be split this line. It's 86 chars long and checkpatch.pl is warning
about this:
Didn't you use arch/powerpc/tools/checkpatch.sh ?
powerpc accepts 90 chars per line.
Christophe
WARNING: line over 80 characters
#257: FILE: arch/powerpc/kernel/hw_breakpoint.c:282:
+ if (!IS_ENABLED(CONFIG_PPC_8xx) && !stepping_handler(regs, bp,
info->address))
[PATCH] kvm: x86: Fix -Wmissing-prototypes warnings
We get a warning when build kernel W=1: arch/x86/kvm/../../../virt/kvm/eventfd.c:48:1: warning: no previous prototype for ‘kvm_arch_irqfd_allowed’ [-Wmissing-prototypes] kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args) ^ The reason is kvm_arch_irqfd_allowed is declared in arch/x86/kvm/irq.h, which is not included by eventfd.c. Remove the declaration to kvm_host.h can fix this. Signed-off-by: Yi Wang --- arch/x86/kvm/irq.h | 1 - include/linux/kvm_host.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h index d6519a3..7c6233d 100644 --- a/arch/x86/kvm/irq.h +++ b/arch/x86/kvm/irq.h @@ -102,7 +102,6 @@ static inline int irqchip_in_kernel(struct kvm *kvm) return mode != KVM_IRQCHIP_NONE; } -bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args); void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu); void kvm_inject_apic_timer_irqs(struct kvm_vcpu *vcpu); void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu); diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index d1ad38a..5f04005 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -990,6 +990,7 @@ void kvm_unregister_irq_ack_notifier(struct kvm *kvm, struct kvm_irq_ack_notifier *kian); int kvm_request_irq_source_id(struct kvm *kvm); void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id); +bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args); /* * search_memslots() and __gfn_to_memslot() are here because they are -- 1.8.3.1
Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform_driver
On Thu, Jul 04, 2019 at 02:17:22PM -0700, Dmitry Torokhov wrote:
> Hi Greg,
>
> On Thu, Jul 4, 2019 at 5:15 AM Greg Kroah-Hartman
> wrote:
> >
> > Platform drivers like to add sysfs groups to their device, but right now
> > they have to do it "by hand". The driver core should handle this for
> > them, but there is no way to get to the bus-default attribute groups as
> > all platform devices are "special and unique" one-off drivers/devices.
> >
> > To combat this, add a dev_groups pointer to platform_driver which allows
> > a platform driver to set up a list of default attributes that will be
> > properly created and removed by the platform driver core when a probe()
> > function is successful and removed right before the device is unbound.
>
> Why is this limited to platform bus? Drivers for other buses also
> often want to augment list of their attributes during probe(). I'd
> move it to generic probe handling.
This is not limited to the platform at all, the driver core supports
this for any bus type today, but it's then up to the bus-specific code
to pass that on to the driver core. That's usually set for the
bus-specific attributes that they want exposed for all devices of that
bus type (see the bus_groups, dev_groups, and drv_groups pointers in
struct bus_type).
For the platform devices, the problem is that this is something that the
individual drivers want after they bind to the device. And as all
platform devices are "different" they can't be a "common" set of
attributes, so they need to be created after the device is bound to the
driver.
> > Cc: Richard Gong
> > Cc: Romain Izard
> > Cc: "Rafael J. Wysocki"
> > Cc: Andy Shevchenko
> > Cc: Mans Rullgard
> > Cc: Bartosz Golaszewski
> > Cc: Randy Dunlap
> > Cc: Johan Hovold
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > v2: addressed Johan's comments by reordering when we remove the files
> > from the device, and clean up on an error in a nicer way. Ended up
> > making the patch smaller overall, always nice.
> >
> > drivers/base/platform.c | 16 +++-
> > include/linux/platform_device.h | 1 +
> > 2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 713903290385..74428a1e03f3 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -614,8 +614,20 @@ static int platform_drv_probe(struct device *_dev)
> >
> > if (drv->probe) {
> > ret = drv->probe(dev);
> > - if (ret)
> > + if (ret) {
> > + dev_pm_domain_detach(_dev, true);
> > + goto out;
> > + }
> > + }
> > + if (drv->dev_groups) {
> > + ret = device_add_groups(_dev, drv->dev_groups);
> > + if (ret) {
> > + if (drv->remove)
> > + drv->remove(dev);
> > dev_pm_domain_detach(_dev, true);
> > + return ret;
> > + }
> > + kobject_uevent(&_dev->kobj, KOBJ_CHANGE);
>
> We already emit KOBJ_BIND when we finish binding device to a driver,
> regardless of the bus. I know we still need to teach systemd to handle
> it properly, but I think it is better than sprinkling KOBJ_CHANGE
> around.
But the object's attributes did just change, which is what KOBJ_CHANGE
tells userspace, so this should be the correct thing to say to
userspace.
And yes, ideally KOBJ_BIND would be handled, and it will be sent once
the device's probe function succeeds, but we have to deal with old
userspaces as well, right?
thanks,
greg k-h
Re: suspend broken in next-20190704 on Thinkpad X60
On Fri, Jul 5, 2019 at 8:50 PM Pavel Machek wrote: > > On Fri 2019-07-05 00:59:35, Rafael J. Wysocki wrote: > > On Thu, Jul 4, 2019 at 9:20 PM Pavel Machek wrote: > > > > > > Hi! > > > > > > Suspend is broken in next-20190704 on Thinkpad X60. > > > > Broken in what way? Any details? > > > > > It very very probably worked ok in 20190701. > > > > Well, please try the linux-next branch from linux-pm.git > > (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git) > > alone and see if that fails. > > So... let me try this one? > > commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch) > treecb5339fcaae2166832f91f4ce9f40575cc6cb6e5 > parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff) > parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff) > download > linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz > Merge branch 'pm-cpufreq-new' into > linux-nexttestinglinux-nextbleeding-edge > * pm-cpufreq-new: > > That one is broken, too. > > pavel@amd:~$ sudo pm-suspend > > Machine suspends, resumes, but I don't get my prompt back. I'm not sure what you mean here. I'm guessing that you don't get back to the console from which you ran the pm-suspend command, but is X restored, for example? Is there any way to get into the system in that state? Anyway, if 5.2-rc7 is OK, something in this branch causes the problem to happen for you. I would try https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244 to narrow down the scope somewhat.
Re: linux-next: Tree for Jul 4
On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> This release produces a whole lot (over 200) of this message in my qemu
> boot tests:
>
> [1.698497] debugfs: File 'sched' already present!
>
> Introduced by commit
>
> 43e23b6c0b01 ("debugfs: log errors when something goes wrong")
>
> from the driver-core tree. I assume that the error(?) was already
> happening, but it is now being reported.
What are you passing to qemu to get this? I just tried it myself and
see no error reports at all. Have a .config I can use to try to
reproduce this?
And from a recent syzbot report, I don't think you are alone, as I saw
the messages showing up there too...
thanks,
greg k-h
[tip:irq/core] genirq: Update irq stats from NMI handlers
Commit-ID: c09cb1293523dd786ae54a12fd88001542cba2f6
Gitweb: https://git.kernel.org/tip/c09cb1293523dd786ae54a12fd88001542cba2f6
Author: Shijith Thotton
AuthorDate: Fri, 5 Jul 2019 07:56:20 +
Committer: Thomas Gleixner
CommitDate: Sat, 6 Jul 2019 10:40:19 +0200
genirq: Update irq stats from NMI handlers
The NMI handlers handle_percpu_devid_fasteoi_nmi() and handle_fasteoi_nmi()
do not update the interrupt counts. Due to that the NMI interrupt count
does not show up correctly in /proc/interrupts.
Add the statistics and treat the NMI handlers in the same way as per cpu
interrupts and prevent them from updating irq_desc::tot_count as this might
be corrupted due to concurrency.
[ tglx: Massaged changelog ]
Fixes: 2dcf1fbcad35 ("genirq: Provide NMI handlers")
Signed-off-by: Shijith Thotton
Signed-off-by: Thomas Gleixner
Link:
https://lkml.kernel.org/r/1562313336-11888-1-git-send-email-sthot...@marvell.com
---
kernel/irq/chip.c| 4
kernel/irq/irqdesc.c | 8 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 29d6c7d070b4..04c850fb70cb 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -748,6 +748,8 @@ void handle_fasteoi_nmi(struct irq_desc *desc)
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
+ __kstat_incr_irqs_this_cpu(desc);
+
trace_irq_handler_entry(irq, action);
/*
* NMIs cannot be shared, there is only one action.
@@ -962,6 +964,8 @@ void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc)
unsigned int irq = irq_desc_get_irq(desc);
irqreturn_t res;
+ __kstat_incr_irqs_this_cpu(desc);
+
trace_irq_handler_entry(irq, action);
res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
trace_irq_handler_exit(irq, action, res);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index c52b737ab8e3..9149dde5a7b0 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -946,6 +946,11 @@ unsigned int kstat_irqs_cpu(unsigned int irq, int cpu)
*per_cpu_ptr(desc->kstat_irqs, cpu) : 0;
}
+static bool irq_is_nmi(struct irq_desc *desc)
+{
+ return desc->istate & IRQS_NMI;
+}
+
/**
* kstat_irqs - Get the statistics for an interrupt
* @irq: The interrupt number
@@ -963,7 +968,8 @@ unsigned int kstat_irqs(unsigned int irq)
if (!desc || !desc->kstat_irqs)
return 0;
if (!irq_settings_is_per_cpu_devid(desc) &&
- !irq_settings_is_per_cpu(desc))
+ !irq_settings_is_per_cpu(desc) &&
+ !irq_is_nmi(desc))
return desc->tot_count;
for_each_possible_cpu(cpu)
[tip:irq/core] irq/irqdomain: Fix comment typo
Commit-ID: 3a1d24ca9573fbc74a3d32c972c333b161e0e9dc Gitweb: https://git.kernel.org/tip/3a1d24ca9573fbc74a3d32c972c333b161e0e9dc Author: Zenghui Yu AuthorDate: Sat, 6 Jul 2019 04:41:12 + Committer: Thomas Gleixner CommitDate: Sat, 6 Jul 2019 10:40:20 +0200 irq/irqdomain: Fix comment typo Fix typo in the comment on top of __irq_domain_add(). Signed-off-by: Zenghui Yu Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/1562388072-23492-1-git-send-email-yuzeng...@huawei.com --- kernel/irq/irqdomain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index e7d17cc3a3d7..3078d0e48bba 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq/irqdomain.c @@ -123,7 +123,7 @@ EXPORT_SYMBOL_GPL(irq_domain_free_fwnode); * @ops: domain callbacks * @host_data: Controller private data pointer * - * Allocates and initialize and irq_domain structure. + * Allocates and initializes an irq_domain structure. * Returns pointer to IRQ domain, or NULL on failure. */ struct irq_domain *__irq_domain_add(struct fwnode_handle *fwnode, int size,
[PATCH] staging: octeon: One function call less in cvm_oct_common_set_multicast_list()
From: Markus Elfring Date: Sat, 6 Jul 2019 10:48:23 +0200 Avoid an extra function call by using a ternary operator instead of a conditional statement. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/staging/octeon/ethernet.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 8847a11c212f..93f127a0b287 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -337,13 +337,8 @@ static void cvm_oct_common_set_multicast_list(struct net_device *dev) cvmx_write_csr(CVMX_GMXX_RXX_ADR_CTL(index, interface), control.u64); - if (dev->flags & IFF_PROMISC) - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 0); - else - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 1); - + cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN(index, interface), + dev->flags & IFF_PROMISC ? 0 : 1); cvmx_write_csr(CVMX_GMXX_PRTX_CFG(index, interface), gmx_cfg.u64); } -- 2.22.0
[PATCH] staging: octeon: One function call less in cvm_oct_common_set_multicast_list()
From: Markus Elfring Date: Sat, 6 Jul 2019 10:48:23 +0200 Avoid an extra function call by using a ternary operator instead of a conditional statement. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/staging/octeon/ethernet.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/staging/octeon/ethernet.c b/drivers/staging/octeon/ethernet.c index 8847a11c212f..93f127a0b287 100644 --- a/drivers/staging/octeon/ethernet.c +++ b/drivers/staging/octeon/ethernet.c @@ -337,13 +337,8 @@ static void cvm_oct_common_set_multicast_list(struct net_device *dev) cvmx_write_csr(CVMX_GMXX_RXX_ADR_CTL(index, interface), control.u64); - if (dev->flags & IFF_PROMISC) - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 0); - else - cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN - (index, interface), 1); - + cvmx_write_csr(CVMX_GMXX_RXX_ADR_CAM_EN(index, interface), + dev->flags & IFF_PROMISC ? 0 : 1); cvmx_write_csr(CVMX_GMXX_PRTX_CFG(index, interface), gmx_cfg.u64); } -- 2.22.0
Re: [PATCH] staging: speakup: One function call less in speakup_win_enable()
Markus Elfring, le sam. 06 juil. 2019 10:15:30 +0200, a ecrit:
> From: Markus Elfring
> Date: Sat, 6 Jul 2019 10:03:56 +0200
>
> Avoid an extra function call by using a ternary operator instead of
> a conditional statement.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Reviewed-by: Samuel Thibault
> ---
> drivers/staging/speakup/main.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 488f2539aa9a..03bbc9a4dbb3 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1917,10 +1917,9 @@ static void speakup_win_enable(struct vc_data *vc)
> return;
> }
> win_enabled ^= 1;
> - if (win_enabled)
> - synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCED));
> - else
> - synth_printf("%s\n", spk_msg_get(MSG_WINDOW_SILENCE_DISABLED));
> + synth_printf("%s\n", spk_msg_get(win_enabled
> + ? MSG_WINDOW_SILENCED
> + : MSG_WINDOW_SILENCE_DISABLED));
> }
>
> static void speakup_bits(struct vc_data *vc)
> --
> 2.22.0
>
--
Samuel
--- christ gives channel operator status to Dieu
-+- #ens-mim and hell -+-
[PATCH RESEND] media: hdpvr: Add device num check and handling
Add hdpvr device num check and error handling
We need to increment the device count atomically before we checkout a
device to make sure that we do not reach the max count, otherwise we get
out-of-bounds errors as reported by syzbot.
Reported-and-tested-by: syzbot+aac8d0d7205f11204...@syzkaller.appspotmail.com
Signed-off-by: Luke Nowakowski-Krijger
---
Changes in V1:
+ add storing of incremented index in dev_num var
+ add bounds check on dev_num and appropriate error handling
- remove attomic_inc_return from inside of hdpvr_register call
drivers/media/usb/hdpvr/hdpvr-core.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c
b/drivers/media/usb/hdpvr/hdpvr-core.c
index 29ac7fc5b039..640ef83b57c9 100644
--- a/drivers/media/usb/hdpvr/hdpvr-core.c
+++ b/drivers/media/usb/hdpvr/hdpvr-core.c
@@ -275,6 +275,7 @@ static int hdpvr_probe(struct usb_interface *interface,
#endif
size_t buffer_size;
int i;
+ int dev_num;
int retval = -ENOMEM;
/* allocate memory for our device state and initialize it */
@@ -371,9 +372,18 @@ static int hdpvr_probe(struct usb_interface *interface,
goto reg_fail;
}
#endif
-
+
+ dev_num = atomic_inc_return(&dev_nr);
+ if (dev_num >= HDPVR_MAX) {
+ v4l2_err(&dev->v4l2_dev,
+"max device number reached, device register failed\n");
+ atomic_dec(&dev_nr);
+ retval = -ENODEV;
+ goto reg_fail;
+ }
+
retval = hdpvr_register_videodev(dev, &interface->dev,
- video_nr[atomic_inc_return(&dev_nr)]);
+ video_nr[dev_num]);
if (retval < 0) {
v4l2_err(&dev->v4l2_dev, "registering videodev failed\n");
goto reg_fail;
--
2.20.1
Re: [PATCH] staging: speakup: One function call less in speakup_win_enable()
On Sat, Jul 06, 2019 at 11:00:19AM +0200, Samuel Thibault wrote: > Markus Elfring, le sam. 06 juil. 2019 10:15:30 +0200, a ecrit: > > From: Markus Elfring > > Date: Sat, 6 Jul 2019 10:03:56 +0200 > > > > Avoid an extra function call by using a ternary operator instead of > > a conditional statement. > > > > This issue was detected by using the Coccinelle software. > > > > Signed-off-by: Markus Elfring > > Reviewed-by: Samuel Thibault Sorry, but this author/bot is in my kill-file and I no longer accept patches from them. And I HATE ternary operators anyway, so it's not like I would take this patch if it came from someone else :) thanks, greg k-h
Re: linux-next: Tree for Jul 4
Hi Greg,
On Sat, 6 Jul 2019 10:34:33 +0200 Greg Kroah-Hartman
wrote:
>
> On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:
> >
> > This release produces a whole lot (over 200) of this message in my qemu
> > boot tests:
> >
> > [1.698497] debugfs: File 'sched' already present!
> >
> > Introduced by commit
> >
> > 43e23b6c0b01 ("debugfs: log errors when something goes wrong")
> >
> > from the driver-core tree. I assume that the error(?) was already
> > happening, but it is now being reported.
>
> What are you passing to qemu to get this? I just tried it myself and
> see no error reports at all. Have a .config I can use to try to
> reproduce this?
It is a powerpc pseries_le_defconfig kernel and I run qemu like this:
qemu-system-ppc64 -M pseries -m 2G -vga none -nographic -kernel vmlinux -initrd
rootfs.cpio.gz
> And from a recent syzbot report, I don't think you are alone, as I saw
> the messages showing up there too...
I feel less lonely, now :-)
--
Cheers,
Stephen Rothwell
pgpliAAhneg0a.pgp
Description: OpenPGP digital signature
Re: linux-next: Tree for Jul 4
On Sat, Jul 06, 2019 at 07:44:12PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Sat, 6 Jul 2019 10:34:33 +0200 Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:
> > >
> > > This release produces a whole lot (over 200) of this message in my qemu
> > > boot tests:
> > >
> > > [1.698497] debugfs: File 'sched' already present!
> > >
> > > Introduced by commit
> > >
> > > 43e23b6c0b01 ("debugfs: log errors when something goes wrong")
> > >
> > > from the driver-core tree. I assume that the error(?) was already
> > > happening, but it is now being reported.
> >
> > What are you passing to qemu to get this? I just tried it myself and
> > see no error reports at all. Have a .config I can use to try to
> > reproduce this?
>
> It is a powerpc pseries_le_defconfig kernel and I run qemu like this:
>
> qemu-system-ppc64 -M pseries -m 2G -vga none -nographic -kernel vmlinux
> -initrd rootfs.cpio.gz
Hm, I think my rootfs initrd might be quite simple compared to yours (it
drops me into a busybox shell). Any pointers to where you created yours
from?
thanks,
greg k-h
Re: kernel BUG at net/rxrpc/local_object.c:LINE!
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: kernel BUG at net/rxrpc/local_object.c:LINE! rxrpc: Assertion failed [ cut here ] kernel BUG at net/rxrpc/local_object.c:468! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 10548 Comm: udevd Not tainted 5.2.0-rc7+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline] RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462 Code: 83 eb 20 e9 74 ff ff ff e8 68 a9 2d fb eb cc 4c 89 ef e8 7e a9 2d fb eb e2 e8 97 f2 f4 fa 48 c7 c7 e0 8c 15 88 e8 2f f8 de fa <0f> 0b e8 84 f2 f4 fa 48 c7 c7 e0 8c 15 88 e8 1c f8 de fa 0f 0b e8 RSP: 0018:8880ae909de8 EFLAGS: 00010282 RAX: 0017 RBX: 0001 RCX: RDX: RSI: 815ad9e6 RDI: ed1015d213af RBP: 8880ae909df8 R08: 0017 R09: ed1015d260a1 R10: ed1015d260a0 R11: 8880ae930507 R12: 888095d10940 R13: 888095d10940 R14: 867b9b10 R15: 8880ae909e78 FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00625208 CR3: a11ba000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __rcu_reclaim kernel/rcu/rcu.h:222 [inline] rcu_do_batch kernel/rcu/tree.c:2092 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2310 [inline] rcu_core+0xba5/0x1500 kernel/rcu/tree.c:2291 __do_softirq+0x25c/0x94c kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x180/0x1d0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x13b/0x550 arch/x86/kernel/apic/apic.c:1068 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:767 [inline] RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline] RIP: 0010:_raw_spin_unlock_irqrestore+0x95/0xe0 kernel/locking/spinlock.c:191 Code: 48 c7 c0 30 76 b2 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 39 48 83 3d 82 18 95 01 00 74 24 48 89 df 57 9d <0f> 1f 44 00 00 bf 01 00 00 00 e8 dc 2e 30 fa 65 8b 05 bd 9f e4 78 RSP: 0018:8880a78bf728 EFLAGS: 0286 ORIG_RAX: ff13 RAX: 11164ec6 RBX: 0286 RCX: 111011248d84 RDX: dc00 RSI: 888089246c00 RDI: 0286 RBP: 8880a78bf738 R08: 888089246380 R09: 888089246c20 R10: R11: R12: 8a758108 R13: 0286 R14: 8a758108 R15: __debug_check_no_obj_freed lib/debugobjects.c:798 [inline] debug_check_no_obj_freed+0x200/0x464 lib/debugobjects.c:817 free_pages_prepare mm/page_alloc.c:1140 [inline] free_pcp_prepare mm/page_alloc.c:1156 [inline] free_unref_page_prepare mm/page_alloc.c:2947 [inline] free_unref_page_list+0x1f9/0xc30 mm/page_alloc.c:3016 release_pages+0x5df/0x1930 mm/swap.c:795 free_pages_and_swap_cache+0x2a0/0x3d0 mm/swap_state.c:295 tlb_batch_pages_flush mm/mmu_gather.c:49 [inline] tlb_flush_mmu_free mm/mmu_gather.c:184 [inline] tlb_flush_mmu+0x89/0x630 mm/mmu_gather.c:191 tlb_finish_mmu+0x98/0x3b0 mm/mmu_gather.c:272 exit_mmap+0x2cd/0x510 mm/mmap.c:3147 __mmput kernel/fork.c:1063 [inline] mmput+0x15f/0x4c0 kernel/fork.c:1084 exec_mmap fs/exec.c:1047 [inline] flush_old_exec+0x8c8/0x1c00 fs/exec.c:1280 load_elf_binary+0xa53/0x56c0 fs/binfmt_elf.c:867 search_binary_handler fs/exec.c:1658 [inline] search_binary_handler+0x16d/0x570 fs/exec.c:1635 exec_binprm fs/exec.c:1701 [inline] __do_execve_file.isra.0+0x1310/0x22f0 fs/exec.c:1821 do_execveat_common fs/exec.c:1868 [inline] do_execve fs/exec.c:1885 [inline] __do_sys_execve fs/exec.c:1961 [inline] __se_sys_execve fs/exec.c:1956 [inline] __x64_sys_execve+0x8f/0xc0 fs/exec.c:1956 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f67dfd66207 Code: Bad RIP value. RSP: 002b:7fff900c3538 EFLAGS: 0202 ORIG_RAX: 003b RAX: ffda RBX: RCX: 7f67dfd66207 RDX: 00695c20 RSI: 7fff900c3630 RDI: 7fff900c4640 RBP: 00625500 R08: 20d5 R09: 20d5 R10: R11: 0202 R12: 00695c20 R13: 0007 R14: 00691250 R15: 0005 Modules linked in: ---[ end trace 5b4a4001a18479d0 ]--- RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline] RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462 Code: 83 eb 20 e9 74 ff ff ff e8 68 a9 2d fb eb cc 4c 89 ef e8 7e a9 2d fb eb e2 e8 97 f2 f4 fa 48 c7 c7 e0 8c 15 88 e8 2f f8 de fa <0f> 0b e8 84 f2 f
Re: [PATCH 4/7] staging: most: Use spinlock_t instead of struct spinlock
On Thu, Jul 04, 2019 at 05:38:00PM +0200, Sebastian Andrzej Siewior wrote: > For spinlocks the type spinlock_t should be used instead of "struct > spinlock". Why? > Use spinlock_t for spinlock's definition. Why? I agree it makes the code smaller, but why is this required? thanks, greg k-h
[PATCH 0/2] regulator: axp20x: Fix bugs for AXP803/6
Driver refactoring caused few bugs and most of them are already fixed. However, some are still present, namely in AXP806 and AXP803 regulator definitions. This short patch series fix them. Please take a look. Best regards, Jernej Jernej Skrabec (2): regulator: axp20x: fix DCDCA and DCDCD for AXP806 regulator: axp20x: fix DCDC6 for AXP803 drivers/regulator/axp20x-regulator.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.22.0
[PATCH 1/2] regulator: axp20x: fix DCDCA and DCDCD for AXP806
Refactoring of the driver introduced few bugs in AXP806's DCDCA and
DCDCD regulator definitions.
Fix them.
Fixes: db4a555f7c4cf ("regulator: axp20x: use defines for masks")
Signed-off-by: Jernej Skrabec
---
drivers/regulator/axp20x-regulator.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 152053361862..c951568994a1 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -240,7 +240,7 @@
#define AXP806_DCDCA_600mV_END \
(AXP806_DCDCA_600mV_START + AXP806_DCDCA_600mV_STEPS)
#define AXP806_DCDCA_1120mV_START 0x33
-#define AXP806_DCDCA_1120mV_STEPS 14
+#define AXP806_DCDCA_1120mV_STEPS 20
#define AXP806_DCDCA_1120mV_END\
(AXP806_DCDCA_1120mV_START + AXP806_DCDCA_1120mV_STEPS)
#define AXP806_DCDCA_NUM_VOLTAGES 72
@@ -774,8 +774,8 @@ static const struct regulator_linear_range
axp806_dcdcd_ranges[] = {
AXP806_DCDCD_600mV_END,
2),
REGULATOR_LINEAR_RANGE(160,
- AXP806_DCDCD_600mV_START,
- AXP806_DCDCD_600mV_END,
+ AXP806_DCDCD_1600mV_START,
+ AXP806_DCDCD_1600mV_END,
10),
};
--
2.22.0
[PATCH 2/2] regulator: axp20x: fix DCDC6 for AXP803
Refactoring of axp20x driver introduced a bug in AXP803's DCDC6
regulator definition.
Fix it.
Fixes: db4a555f7c4cf ("regulator: axp20x: use defines for masks")
Signed-off-by: Jernej Skrabec
---
drivers/regulator/axp20x-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index c951568994a1..29b92ce521b7 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -181,7 +181,7 @@
#define AXP803_DCDC6_600mV_END \
(AXP803_DCDC6_600mV_START + AXP803_DCDC6_600mV_STEPS)
#define AXP803_DCDC6_1120mV_START 0x33
-#define AXP803_DCDC6_1120mV_STEPS 14
+#define AXP803_DCDC6_1120mV_STEPS 20
#define AXP803_DCDC6_1120mV_END\
(AXP803_DCDC6_1120mV_START + AXP803_DCDC6_1120mV_STEPS)
#define AXP803_DCDC6_NUM_VOLTAGES 72
--
2.22.0
Re: [PATCH v2] nvme: fix multipath crash when ANA desactivated
On 7/5/2019 5:05 PM, Marta Rybczynska wrote: Fix a crash with multipath activated. It happends when ANA log page is larger than MDTS and because of that ANA is disabled. The driver then tries to access unallocated buffer when connecting to a nvme target. The signature is as follows: [ 300.433586] nvme nvme0: ANA log page size (8208) larger than MDTS (8192). [ 300.435387] nvme nvme0: disabling ANA support. [ 300.437835] nvme nvme0: creating 4 I/O queues. [ 300.459132] nvme nvme0: new ctrl: NQN "nqn.0.0.0", addr 10.91.0.1:8009 [ 300.464609] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 300.466342] #PF error: [normal kernel read fault] [ 300.467385] PGD 0 P4D 0 [ 300.467987] Oops: [#1] SMP PTI [ 300.468787] CPU: 3 PID: 50 Comm: kworker/u8:1 Not tainted 5.0.20kalray+ #4 [ 300.470264] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 300.471532] Workqueue: nvme-wq nvme_scan_work [nvme_core] [ 300.472724] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core] [ 300.474038] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48 [ 300.477374] RSP: 0018:a50e80fd7cb8 EFLAGS: 00010296 [ 300.478334] RAX: 0001 RBX: 9130f1872258 RCX: [ 300.479784] RDX: c06c4c30 RSI: 9130edad4280 RDI: 9130f1872258 [ 300.481488] RBP: R08: 0001 R09: 0044 [ 300.483203] R10: 0220 R11: 0040 R12: 9130f18722c0 [ 300.484928] R13: 9130f18722d0 R14: 9130edad4280 R15: 9130f18722c0 [ 300.486626] FS: () GS:9130f7b8() knlGS: [ 300.488538] CS: 0010 DS: ES: CR0: 80050033 [ 300.489907] CR2: 0008 CR3: 0002365e6000 CR4: 06e0 [ 300.491612] DR0: DR1: DR2: [ 300.493303] DR3: DR6: fffe0ff0 DR7: 0400 [ 300.494991] Call Trace: [ 300.495645] nvme_mpath_add_disk+0x5c/0xb0 [nvme_core] [ 300.496880] nvme_validate_ns+0x2ef/0x550 [nvme_core] [ 300.498105] ? nvme_identify_ctrl.isra.45+0x6a/0xb0 [nvme_core] [ 300.499539] nvme_scan_work+0x2b4/0x370 [nvme_core] [ 300.500717] ? __switch_to_asm+0x35/0x70 [ 300.501663] process_one_work+0x171/0x380 [ 300.502340] worker_thread+0x49/0x3f0 [ 300.503079] kthread+0xf8/0x130 [ 300.503795] ? max_active_store+0x80/0x80 [ 300.504690] ? kthread_bind+0x10/0x10 [ 300.505502] ret_from_fork+0x35/0x40 [ 300.506280] Modules linked in: nvme_tcp nvme_rdma rdma_cm iw_cm ib_cm ib_core nvme_fabrics nvme_core xt_physdev ip6table_raw ip6table_mangle ip6table_filter ip6_tables xt_comment iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_CHECKSUM iptable_mangle iptable_filter veth ebtable_filter ebtable_nat ebtables iptable_raw vxlan ip6_udp_tunnel udp_tunnel sunrpc joydev pcspkr virtio_balloon br_netfilter bridge stp llc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net virtio_console net_failover virtio_blk failover ata_piix serio_raw libata virtio_pci virtio_ring virtio [ 300.514984] CR2: 0008 [ 300.515569] ---[ end trace faa2eefad7e7f218 ]--- [ 300.516354] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core] [ 300.517330] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48 [ 300.520353] RSP: 0018:a50e80fd7cb8 EFLAGS: 00010296 [ 300.521229] RAX: 0001 RBX: 9130f1872258 RCX: [ 300.522399] RDX: c06c4c30 RSI: 9130edad4280 RDI: 9130f1872258 [ 300.523560] RBP: R08: 0001 R09: 0044 [ 300.524734] R10: 0220 R11: 0040 R12: 9130f18722c0 [ 300.525915] R13: 9130f18722d0 R14: 9130edad4280 R15: 9130f18722c0 [ 300.527084] FS: () GS:9130f7b8() knlGS: [ 300.528396] CS: 0010 DS: ES: CR0: 80050033 [ 300.529440] CR2: 0008 CR3: 0002365e6000 CR4: 06e0 [ 300.530739] DR0: DR1: DR2: [ 300.531989] DR3: DR6: fffe0ff0 DR7: 0400 [ 300.533264] Kernel panic - not syncing: Fatal exception [ 300.534338] Kernel Offset: 0x17c0 from 0x8100 (relocation range: 0x8000-0xbfff) [ 300.536227] ---[ end Kernel panic - not syncing: Fatal exception ]--- Signed-off-by: Marta Rybczynska Tested-by: Jean-Baptiste Riaux --- drivers/nvme/host/multipath.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/mul
Re: linux-next: Tree for Jul 4
Hi Greg,
On Sat, 6 Jul 2019 11:46:47 +0200 Greg Kroah-Hartman
wrote:
>
> On Sat, Jul 06, 2019 at 07:44:12PM +1000, Stephen Rothwell wrote:
> >
> > On Sat, 6 Jul 2019 10:34:33 +0200 Greg Kroah-Hartman
> > wrote:
> > >
> > > On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:
> > > >
> > > > This release produces a whole lot (over 200) of this message in my qemu
> > > > boot tests:
> > > >
> > > > [1.698497] debugfs: File 'sched' already present!
> > > >
> > > > Introduced by commit
> > > >
> > > > 43e23b6c0b01 ("debugfs: log errors when something goes wrong")
> > > >
> > > > from the driver-core tree. I assume that the error(?) was already
> > > > happening, but it is now being reported.
> > >
> > > What are you passing to qemu to get this? I just tried it myself and
> > > see no error reports at all. Have a .config I can use to try to
> > > reproduce this?
> >
> > It is a powerpc pseries_le_defconfig kernel and I run qemu like this:
> >
> > qemu-system-ppc64 -M pseries -m 2G -vga none -nographic -kernel vmlinux
> > -initrd rootfs.cpio.gz
>
> Hm, I think my rootfs initrd might be quite simple compared to yours (it
> drops me into a busybox shell). Any pointers to where you created yours
> from?
Michael Ellerman gave it to me. It is very simple. Its /init is just
$ cat init
#!/bin/sh
# devtmpfs does not get automounted for initramfs
/bin/mount -t devtmpfs devtmpfs /dev
exec 0/dev/console
exec 2>/dev/console
exec /sbin/init $*
and /sbin/init is a link to /bin/busybox
It is all run by an expect script that just waits for the login:
prompt, logs in a root and runs "halt".
All the debugfs messages appear before the kernel finished booting.
--
Cheers,
Stephen Rothwell
pgpVU47jav6ao.pgp
Description: OpenPGP digital signature
Re: [PATCH] Bluetooth: hci_ldisc: check for missing tty operations
Hi Vladis, > Certain ttys lack operations (eg: pty_unix98_ops) which still can be > called by certain hci uart proto (eg: mrvl, ath). Currently this leads > to execution at address 0x0. Fix this by adding checks for missing tty > operations. so I really prefer that we just fail setting the line discipline. These drivers need to check that the underlying transport has all the operations available they need. We can not just ignore them. Regards Marcel
Re: [PATCH v3 2/2] Bluetooth: hci_ldisc: Add NULL check for tiocmget() and tiocmset() in hci_uart_set_flow_control()
Hi Myungho,
> tiocmget() or tiocmset() operations are optional. Just return from
> hci_uart_set_flow_control() if tiocmget() or tiocmset() operation is
> NULL.
>
> Fixes: 2a973dfada2b ("hci_uart: Add new line discipline enhancements")
> Cc: # 4.2
> Signed-off-by: Myungho Jung
> ---
> Changes in v2:
> - Remove braces in if statment
>
> Changes in v3:
> - Split into 2 patches
> - Add stable CC and fixes tags
>
> drivers/bluetooth/hci_ldisc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index fbf7b4df23ab..cb31c2d8d826 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -314,6 +314,10 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool
> enable)
> return;
> }
>
> + /* tiocmget() and tiocmset() operations are optional */
> + if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset)
> + return;
> +
lets just fail setting the line discipline if these ops are not available.
Doing some silent ignoring is not going to help.
Regards
Marcel
Re: [PATCH][next] 6lowpan: fix off-by-one comparison of index id with LOWPAN_IPHC_CTX_TABLE_SIZE
Hi Colin, > The WARN_ON_ONCE check on id is off-by-one, it should be greater or equal > to LOWPAN_IPHC_CTX_TABLE_SIZE and not greater than. Fix this. > > Signed-off-by: Colin Ian King > --- > net/6lowpan/debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/6lowpan/debugfs.c b/net/6lowpan/debugfs.c > index 1c140af06d52..a510bed8165b 100644 > --- a/net/6lowpan/debugfs.c > +++ b/net/6lowpan/debugfs.c > @@ -170,7 +170,7 @@ static void lowpan_dev_debugfs_ctx_init(struct net_device > *dev, > struct dentry *root; > char buf[32]; > > - WARN_ON_ONCE(id > LOWPAN_IPHC_CTX_TABLE_SIZE); > + WARN_ON_ONCE(id >= LOWPAN_IPHC_CTX_TABLE_SIZE); this patch no longer applied cleanly to bluetooth-next. Can you send me an updated version. Regards Marcel
Re: [PATCH v9] Bluetooth: btqca: inject command complete event during fw download
Hi Matthias, > Latest qualcomm chips are not sending an command complete event for > every firmware packet sent to chip. They only respond with a vendor > specific event for the last firmware packet. This optimization will > decrease the BT ON time. Due to this we are seeing a timeout error > message logs on the console during firmware download. Now we are > injecting a command complete event once we receive an vendor specific > event for the last RAM firmware packet. > > Signed-off-by: Balakrishna Godavarthi > Tested-by: Matthias Kaehlcke > Reviewed-by: Matthias Kaehlcke > Signed-off-by: Matthias Kaehlcke > --- > Changes in v9: > - define QCA_HCI_CC_SUCCESS (again) > - use QCA_HCI_CC_OPCODE instead of HCI_OP_NOP > > Changes in v8: > - renamed QCA_HCI_CC_SUCCESS to QCA_HCI_CC_OPCODE > - use 0xFC00 as opcode of the injected event instead of 0 > - added Matthias' tags from the v7 review > --- > drivers/bluetooth/btqca.c | 39 ++- > drivers/bluetooth/btqca.h | 4 > 2 files changed, 42 insertions(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v4] Bluetooth: hci_qca: wcn3990: Drop baudrate change vendor event
Hi Matthias, > Firmware download to the WCN3990 often fails with a 'TLV response size > mismatch' error: > > [ 133.064659] Bluetooth: hci0: setting up wcn3990 > [ 133.489150] Bluetooth: hci0: QCA controller version 0x02140201 > [ 133.495245] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv > [ 133.507214] Bluetooth: hci0: QCA TLV response size mismatch > [ 133.513265] Bluetooth: hci0: QCA Failed to download patch (-84) > > This is caused by a vendor event that corresponds to an earlier command > to change the baudrate. The event is not processed in the context of the > baudrate change and is later interpreted as response to the firmware > download command (which is also a vendor command), but the driver detects > that the event doesn't have the expected amount of associated data. > > More details: > > For the WCN3990 the vendor command for a baudrate change isn't sent as > synchronous HCI command, because the controller sends the corresponding > vendor event with the new baudrate. The event is received and decoded > after the baudrate change of the host port. > > Identify the 'unused' event when it is received and don't add it to > the queue of RX frames. > > Signed-off-by: Matthias Kaehlcke > --- > Changes in v4: > - limit the fix to WCN3990 instead of applying it to all WCN399x. > Harish Bandi reported frame reassembly > errors with WCN3998 and v3. At this point it is unknown in how far > WCN3998 behaves different from WCN3990, we can revisit > it later if it turns that it has the same problem. > > Changes in v3: > - rebased on latest bluetooth-next/master > - removed barrier calls again, bit routines include barriers > > Changes in v2: > - make QCA_DROP_VENDOR_EVENT an enum value and don't use BIT() > - free skb in qca_recv_event() > - add barriers to ensure qca_recv_event() sees updated flags > - return -ETIMEDOUT instead of -EPROTO if the vendor event isn't > received in time > --- > drivers/bluetooth/hci_qca.c | 55 - > 1 file changed, 54 insertions(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] bluetooth: Cleanup formatting and coding style
Hi Fabian, > Fix some warnings and one error reported by checkpatch.pl: > - lines longer than 80 characters are wrapped > - empty lines inserted to separate variable declarations from the actual > code > - line break inserted after if (...) > > Co-developed-by: Thomas Röthenbacher > Signed-off-by: Thomas Röthenbacher > Signed-off-by: Fabian Schindlatz > Cc: linux-ker...@i4.cs.fau.de > --- > drivers/bluetooth/bpa10x.c | 3 ++- > drivers/bluetooth/hci_ll.c | 25 ++--- > 2 files changed, 20 insertions(+), 8 deletions(-) patch has been applied to bluetooth-next. Regards Marcel
Re: [PATCH] Bluetooth: serdev: hci_ll: set operational frequency earlier
Hi Philipp, > Uploading the firmware needs quite a few seconds if done at 115200 kbps. So > set > the operational frequency, usually 3 MHz, before uploading the firmware. > > I have successfully tested this with a wl1837mod. > > Signed-off-by: Philipp Puschmann > --- > drivers/bluetooth/hci_ll.c | 39 -- > 1 file changed, 21 insertions(+), 18 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] bluetooth: hci_ll: Refactor download_firmware
Hi Fabian, > Extract the new function send_command_from_firmware from > download_firmware, which helps with the readability of the switch > statement. This way the code is less deeply nested and also no longer > exceeds the 80 character limit. > > Co-developed-by: Thomas Röthenbacher > Signed-off-by: Thomas Röthenbacher > Signed-off-by: Fabian Schindlatz > --- > drivers/bluetooth/hci_ll.c | 45 -- > 1 file changed, 28 insertions(+), 17 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v6 1/2] Bluetooth: hci_qca: Load customized NVM based on the device property
Hi Rocky, > QCA BTSOC NVM is a customized firmware file and different vendors may > want to have different BTSOC configuration (e.g. Configure SCO over PCM > or I2S, Setting Tx power, etc.) via this file. This patch will allow > vendors to download different NVM firmware file by reading a device > property "firmware-name". > > Signed-off-by: Rocky Liao > --- > Changes in v6: > * Added read firmware-name property for both QCA6174 and WCN399X > --- > drivers/bluetooth/btqca.c | 8 ++-- > drivers/bluetooth/btqca.h | 6 -- > drivers/bluetooth/hci_qca.c | 18 +- > 3 files changed, 27 insertions(+), 5 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v3] Bluetooth: btrtl: HCI reset on close for Realtek BT chip
Hi Jian-Hong, > Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly > after on-off several times. Bluetooth daemon sets BT mode failed when > this issue happens. Scanning must be active while turning off for this > bug to be hit. > > bluetoothd[1576]: Failed to set mode: Failed (0x03) > > If BT is turned off, then turned on again, it works correctly again. > > According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set > during probing. So, this patch makes Realtek's BT reset on close to fix > this issue. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429 > Signed-off-by: Jian-Hong Pan > --- > v2: > - According to the vendor driver, it makes "all" Realtek's BT reset on > close. So, this version makes it the same. > - Change to the new subject for all Realtek BT chips. > > v3: > - Fix the commit message and add the bug link. > - Have btrtl_shutdown_realtek() which sends HCI reset command and as > the callback function of hdev->shutdown for Realtek BT instead of > setting HCI_QUIRK_RESET_ON_CLOSE flag. > > drivers/bluetooth/btrtl.c | 20 > drivers/bluetooth/btrtl.h | 6 ++ > drivers/bluetooth/btusb.c | 1 + > 3 files changed, 27 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
[PATCH v5 02/12] S.A.R.A.: create framework
Initial S.A.R.A. framework setup. Creation of a simplified interface to securityfs API to store and retrieve configurations and flags from user-space. Creation of some generic functions and macros to handle concurrent access to configurations, memory allocation and path resolution. Signed-off-by: Salvatore Mesoraca --- security/Kconfig | 11 +- security/Makefile | 2 + security/sara/Kconfig | 40 +++ security/sara/Makefile | 3 + security/sara/include/sara.h | 29 ++ security/sara/include/securityfs.h | 61 security/sara/include/utils.h | 80 ++ security/sara/main.c | 115 security/sara/securityfs.c | 565 + security/sara/utils.c | 92 ++ 10 files changed, 993 insertions(+), 5 deletions(-) create mode 100644 security/sara/Kconfig create mode 100644 security/sara/Makefile create mode 100644 security/sara/include/sara.h create mode 100644 security/sara/include/securityfs.h create mode 100644 security/sara/include/utils.h create mode 100644 security/sara/main.c create mode 100644 security/sara/securityfs.c create mode 100644 security/sara/utils.c diff --git a/security/Kconfig b/security/Kconfig index 466cc1f..4cae0ec 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -237,6 +237,7 @@ source "security/apparmor/Kconfig" source "security/loadpin/Kconfig" source "security/yama/Kconfig" source "security/safesetid/Kconfig" +source "security/sara/Kconfig" source "security/integrity/Kconfig" @@ -276,11 +277,11 @@ endchoice config LSM string "Ordered list of enabled LSMs" - default "yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor" if DEFAULT_SECURITY_SMACK - default "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" if DEFAULT_SECURITY_APPARMOR - default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO - default "yama,loadpin,safesetid,integrity" if DEFAULT_SECURITY_DAC - default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor" + default "yama,loadpin,safesetid,integrity,sara,smack,selinux,tomoyo,apparmor" if DEFAULT_SECURITY_SMACK + default "yama,loadpin,safesetid,integrity,sara,apparmor,selinux,smack,tomoyo" if DEFAULT_SECURITY_APPARMOR + default "yama,loadpin,safesetid,integrity,sara,tomoyo" if DEFAULT_SECURITY_TOMOYO + default "yama,loadpin,safesetid,integrity,sara" if DEFAULT_SECURITY_DAC + default "yama,loadpin,safesetid,integrity,sara,selinux,smack,tomoyo,apparmor" help A comma-separated list of LSMs, in initialization order. Any LSMs left off this list will be ignored. This can be diff --git a/security/Makefile b/security/Makefile index c598b90..4b0fd11 100644 --- a/security/Makefile +++ b/security/Makefile @@ -11,6 +11,7 @@ subdir-$(CONFIG_SECURITY_APPARMOR)+= apparmor subdir-$(CONFIG_SECURITY_YAMA) += yama subdir-$(CONFIG_SECURITY_LOADPIN) += loadpin subdir-$(CONFIG_SECURITY_SAFESETID)+= safesetid +subdir-$(CONFIG_SECURITY_SARA) += sara # always enable default capabilities obj-y += commoncap.o @@ -27,6 +28,7 @@ obj-$(CONFIG_SECURITY_APPARMOR) += apparmor/ obj-$(CONFIG_SECURITY_YAMA)+= yama/ obj-$(CONFIG_SECURITY_LOADPIN) += loadpin/ obj-$(CONFIG_SECURITY_SAFESETID) += safesetid/ +obj-$(CONFIG_SECURITY_SARA)+= sara/ obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o # Object integrity file lists diff --git a/security/sara/Kconfig b/security/sara/Kconfig new file mode 100644 index 000..0456220 --- /dev/null +++ b/security/sara/Kconfig @@ -0,0 +1,40 @@ +menuconfig SECURITY_SARA + bool "S.A.R.A." + depends on SECURITY + select SECURITYFS + default n + help + This selects S.A.R.A. LSM which aims to collect heterogeneous + security measures providing a common interface to manage them. + This LSM will always be stacked with the selected primary LSM and + other stacked LSMs. + Further information can be found in + Documentation/admin-guide/LSM/SARA.rst. + + If unsure, answer N. + +config SECURITY_SARA_DEFAULT_DISABLED + bool "S.A.R.A. will be disabled at boot." + depends on SECURITY_SARA + default n + help + If you say Y here, S.A.R.A. will not be enabled at startup. You can + override this option at boot time via "sara.enabled=[1|0]" kernel + parameter or via user-space utilities. + This option is useful for distro kernels. + + If unsure, answer N. + +config SECURITY_SARA_NO_RUNTIME_ENABLE + bool "S.A.R.A. can be turn on only at boot time." + depends on SECURITY_SARA_DEFAULT_DISABLED + default y + help + By enabling this option it wo
[PATCH v5 00/12] S.A.R.A. a new stacked LSM
S.A.R.A. (S.A.R.A. is Another Recursive Acronym) is a stacked Linux Security Module that aims to collect heterogeneous security measures, providing a common interface to manage them. It can be useful to allow minor security features to use advanced management options, like user-space configuration files and tools, without too much overhead. Some submodules that use this framework are also introduced. The code is quite long, I apologize for this. Thank you in advance to anyone who will take the time to review this patchset. S.A.R.A. is meant to be stacked but it needs cred blobs and the procattr interface, so I temporarily implemented those parts in a way that won't be acceptable for upstream, but it works for now. I know that there is some ongoing work to make cred blobs and procattr stackable, as soon as the new interfaces will be available I'll reimplement the involved parts. At the moment I've been able to test it only on x86. The only submodule introduced in this patchset is WX Protection. The kernel-space part is complemented by its user-space counterpart: saractl [1]. A test suite for WX Protection, called sara-test [2], is also available. WX Protection aims to improve user-space programs security by applying: - W^X enforcement: program can't have a page of memory that is marked, at the same time, writable and executable. - W!->X restriction: any page that could have been marked as writable in the past won't ever be allowed to be marked as executable. - Executable MMAP prevention: prevents the creation of new executable mmaps after the dynamic libraries have been loaded. All of the above features can be enabled or disabled both system wide or on a per executable basis through the use of configuration files managed by "saractl". It is important to note that some programs may have issues working with WX Protection. In particular: - W^X enforcement will cause problems to any programs that needs memory pages mapped both as writable and executable at the same time e.g. programs with executable stack markings in the PT_GNU_STACK segment. - W!->X restriction will cause problems to any program that needs to generate executable code at run time or to modify executable pages e.g. programs with a JIT compiler built-in or linked against a non-PIC library. - Executable MMAP prevention can work only with programs that have at least partial RELRO support. It's disabled automatically for programs that lack this feature. It will cause problems to any program that uses dlopen or tries to do an executable mmap. Unfortunately this feature is the one that could create most problems and should be enabled only after careful evaluation. To extend the scope of the above features, despite the issues that they may cause, they are complemented by: - procattr interface: can be used by a program to discover which WX Protection features are enabled and/or to tighten them. - Trampoline emulation: emulates the execution of well-known "trampolines" even when they are placed in non-executable memory. Parts of WX Protection are inspired by some of the features available in PaX. Thanks to the addition of extended attributes support, it's now possible to use S.A.R.A. without being forced to rely on any special userspace tool. More information can be found in the documentation introduced in the first patch and in the "commit message" of the following emails. Changes in v2: - Removed USB filtering submodule and relative hook - s/saralib/libsara/ typo - STR macro renamed to avoid conflicts - check_vmflags hook now returns an error code instead of just 1 or 0. (suggested by Casey Schaufler) - pr_wxp macro rewritten as function for readability - Fixed i386 compilation warnings - Documentation now states clearly that changes done via procattr interface only apply to current thread. (suggested by Jann Horn) Changes in v3: - Documentation has been moved to match the new directory structure. - Kernel cmdline arguments are now accessed via module_param interface (suggested by Kees Cook). - Created "sara_warn_or_return" macro to make WX Protection code more readable (suggested by Kees Cook). - Added more comments, in the most important places, to clarify my intentions (suggested by Kees Cook). - The "pagefault_handler" hook has been rewritten in a more "arch agnostic" way. Though it only support x86 at the moment (suggested by Kees Cook). Changes in v4: - Documentation improved and some mistakes have been fixed. - Reduced dmesg verbosity. - check_vmflags is now also used to decide whether to ignore GNU executable stack markings or not. - Added the check_vmfla
[PATCH v5 01/12] S.A.R.A.: add documentation
Adding documentation for S.A.R.A. LSM. Signed-off-by: Salvatore Mesoraca --- Documentation/admin-guide/LSM/SARA.rst | 177 Documentation/admin-guide/LSM/index.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 24 3 files changed, 202 insertions(+) create mode 100644 Documentation/admin-guide/LSM/SARA.rst diff --git a/Documentation/admin-guide/LSM/SARA.rst b/Documentation/admin-guide/LSM/SARA.rst new file mode 100644 index 000..fdde04c --- /dev/null +++ b/Documentation/admin-guide/LSM/SARA.rst @@ -0,0 +1,177 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +S.A.R.A. + + +S.A.R.A. (S.A.R.A. is Another Recursive Acronym) is a stacked Linux Security +Module that aims to collect heterogeneous security measures, providing a common +interface to manage them. +As of today it consists of one submodule: + +- WX Protection + + +The kernel-space part is complemented by its user-space counterpart: `saractl` +[2]_. +A test suite for WX Protection, called `sara-test` [4]_, is also available. +More information about where to find these tools and the full S.A.R.A. +documentation are in the `External Links and Documentation`_ section. + +--- + +S.A.R.A.'s Submodules += + +WX Protection +- +WX Protection aims to improve user-space programs security by applying: + +- `W^X enforcement`_ +- `W!->X (once writable never executable) mprotect restriction`_ +- `Executable MMAP prevention`_ + +All of the above features can be enabled or disabled both system wide +or on a per executable basis through the use of configuration files managed by +`saractl` [2]_. + +It is important to note that some programs may have issues working with +WX Protection. In particular: + +- **W^X enforcement** will cause problems to any programs that needs + memory pages mapped both as writable and executable at the same time e.g. + programs with executable stack markings in the *PT_GNU_STACK* segment. +- **W!->X mprotect restriction** will cause problems to any program that + needs to generate executable code at run time or to modify executable + pages e.g. programs with a *JIT* compiler built-in or linked against a + *non-PIC* library. +- **Executable MMAP prevention** can work only with programs that have at least + partial *RELRO* support. It's disabled automatically for programs that + lack this feature. It will cause problems to any program that uses *dlopen* + or tries to do an executable mmap. Unfortunately this feature is the one + that could create most problems and should be enabled only after careful + evaluation. + +To extend the scope of the above features, despite the issues that they may +cause, they are complemented by **/proc/PID/attr/sara/wxprot** interface +and **trampoline emulation**. + +At the moment, WX Protection (unless specified otherwise) should work on +any architecture supporting the NX bit, including, but not limited to: +`x86_64`, `x86_32` (with PAE), `ARM` and `ARM64`. + +Parts of WX Protection are inspired by some of the features available in PaX. + +For further information about configuration file format and user-space +utilities please take a look at the full documentation [1]_. + +W^X enforcement +^^^ +W^X means that a program can't have a page of memory that is marked, at the +same time, writable and executable. This also allow to detect many bad +behaviours that make life much more easy for attackers. Programs running with +this feature enabled will be more difficult to exploit in the case they are +affected by some vulnerabilities, because the attacker will be forced +to make more steps in order to exploit them. +This feature also blocks accesses to /proc/*/mem files that would allow to +write the current process read-only memory, bypassing any protection. + +W!->X (once writable never executable) mprotect restriction +^^^ +"Once writable never executable" means that any page that could have been +marked as writable in the past won't ever be allowed to be marked (e.g. via +an mprotect syscall) as executable. +This goes on the same track as W^X, but is much stricter and prevents +the runtime creation of new executable code in memory. +Obviously, this feature does not prevent a program from creating a new file and +*mmapping* it as executable, however, it will be way more difficult for +attackers to exploit vulnerabilities if this feature is enabled. + +Executable MMAP prevention +^^ +This feature prevents the creation of new executable mmaps after the dynamic +libraries have been loaded. When used in combination with **W!->X mprotect +restriction** this feature will completely prevent the creation of new +executable code from the current thread. +Obviously, this feature does not prevent cases in which an attacker uses an +*execve* to
[PATCH v5 09/12] S.A.R.A.: WX protection procattr interface
This allow threads to get current WX Protection flags for themselves or
for other threads (if they have CAP_MAC_ADMIN).
It also allow a thread to set itself flags to a stricter set of rules than
the current one.
Via a new wxprot flag (SARA_WXP_FORCE_WXORX) is it possible to ask the
kernel to rescan the memory and remove the VM_WRITE flag from any area
that is marked both writable and executable.
Protections that prevent the runtime creation of executable code
can be troublesome for all those programs that actually need to do it
e.g. programs shipping with a JIT compiler built-in.
This feature can be use to run the JIT compiler with few restrictions while
enforcing full WX Protection in the rest of the program.
To simplify access to this interface a CC0 licensed library is available
here: https://github.com/smeso/libsara
Signed-off-by: Salvatore Mesoraca
---
fs/proc/base.c | 11
security/sara/wxprot.c | 150 +
2 files changed, 161 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 255f675..7873d27 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2612,6 +2612,13 @@ static ssize_t proc_pid_attr_write(struct file * file,
const char __user * buf,
LSM_DIR_OPS(smack);
#endif
+#ifdef CONFIG_SECURITY_SARA
+static const struct pid_entry sara_attr_dir_stuff[] = {
+ ATTR("sara", "wxprot", 0666),
+};
+LSM_DIR_OPS(sara);
+#endif
+
static const struct pid_entry attr_dir_stuff[] = {
ATTR(NULL, "current", 0666),
ATTR(NULL, "prev", 0444),
@@ -2623,6 +2630,10 @@ static ssize_t proc_pid_attr_write(struct file * file,
const char __user * buf,
DIR("smack",0555,
proc_smack_attr_dir_inode_ops, proc_smack_attr_dir_ops),
#endif
+#ifdef CONFIG_SECURITY_SARA
+ DIR("sara", 0555,
+ proc_sara_attr_dir_inode_ops, proc_sara_attr_dir_ops),
+#endif
};
static int proc_attr_dir_readdir(struct file *file, struct dir_context *ctx)
diff --git a/security/sara/wxprot.c b/security/sara/wxprot.c
index 9c42bfc..84f7b1e 100644
--- a/security/sara/wxprot.c
+++ b/security/sara/wxprot.c
@@ -14,6 +14,7 @@
#ifdef CONFIG_SECURITY_SARA_WXPROT
#include
+#include
#include
#include
#include
@@ -42,6 +43,7 @@
#define SARA_WXP_COMPLAIN 0x0010
#define SARA_WXP_VERBOSE 0x0020
#define SARA_WXP_MMAP 0x0040
+#define SARA_WXP_FORCE_WXORX 0x0080
#define SARA_WXP_EMUTRAMP 0x0100
#define SARA_WXP_TRANSFER 0x0200
#define SARA_WXP_NONE 0x
@@ -540,6 +542,152 @@ static int sara_pagefault_handler(struct pt_regs *regs,
}
#endif
+static int sara_getprocattr(struct task_struct *p, char *name, char **value)
+{
+ int ret;
+ u16 flags;
+ char *buf;
+
+ ret = -EINVAL;
+ if (strcmp(name, "wxprot") != 0)
+ goto out;
+
+ ret = -EACCES;
+ if (unlikely(current != p &&
+!capable(CAP_MAC_ADMIN)))
+ goto out;
+
+ ret = -ENOMEM;
+ buf = kzalloc(8, GFP_KERNEL);
+ if (unlikely(buf == NULL))
+ goto out;
+
+ if (!sara_enabled || !wxprot_enabled) {
+ flags = 0x0;
+ } else {
+ rcu_read_lock();
+ flags = get_sara_wxp_flags(__task_cred(p));
+ rcu_read_unlock();
+ }
+
+ snprintf(buf, 8, "0x%04x\n", flags);
+ ret = strlen(buf);
+ *value = buf;
+
+out:
+ return ret;
+}
+
+static int sara_setprocattr(const char *name, void *value, size_t size)
+{
+ int ret;
+ struct vm_area_struct *vma;
+ struct cred *new = prepare_creds();
+ u16 cur_flags;
+ u16 req_flags;
+ char *buf = NULL;
+
+ ret = -EINVAL;
+ if (!sara_enabled || !wxprot_enabled)
+ goto error;
+ if (unlikely(new == NULL))
+ return -ENOMEM;
+ if (strcmp(name, "wxprot") != 0)
+ goto error;
+ if (unlikely(value == NULL || size == 0 || size > 7))
+ goto error;
+ ret = -ENOMEM;
+ buf = kmalloc(size+1, GFP_KERNEL);
+ if (unlikely(buf == NULL))
+ goto error;
+ buf[size] = '\0';
+ memcpy(buf, value, size);
+ ret = -EINVAL;
+ if (unlikely(strlen(buf) != size))
+ goto error;
+ if (unlikely(kstrtou16(buf, 0, &req_flags) != 0))
+ goto error;
+ /*
+* SARA_WXP_FORCE_WXORX is a procattr only flag with a special
+* meaning and it isn't recognized by are_flags_valid
+*/
+ if (unlikely(!are_flags_valid(req_flags & ~SARA_WXP_FORCE_WXORX)))
+ goto error;
+ /*
+* Extra checks on requested flags:
+* - SARA_WXP_FORCE_WXORX requires SARA_WXP_WXORX
+* - SARA_WXP_MMAP can only be activated if the program
+* has a relro section
+* - COMPLAIN mode can only be requested i
[PATCH v5 11/12] S.A.R.A.: /proc/*/mem write limitation
Prevent a task from opening, in "write" mode, any /proc/*/mem
file that operates on the task's mm.
A process could use it to overwrite read-only memory, bypassing
S.A.R.A. restrictions.
Signed-off-by: Salvatore Mesoraca
---
security/sara/include/sara_data.h | 18 -
security/sara/sara_data.c | 8
security/sara/wxprot.c| 41 +++
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/security/sara/include/sara_data.h
b/security/sara/include/sara_data.h
index 9216c47..ee95f74 100644
--- a/security/sara/include/sara_data.h
+++ b/security/sara/include/sara_data.h
@@ -15,6 +15,7 @@
#define __SARA_DATA_H
#include
+#include
#include
#include
#include
@@ -40,6 +41,10 @@ struct sara_shm_data {
spinlock_t lock;
};
+struct sara_inode_data {
+ struct task_struct *task;
+};
+
static inline struct sara_data *get_sara_data(const struct cred *cred)
{
@@ -79,6 +84,17 @@ static inline struct sara_shm_data *get_sara_shm_data(
#define lock_sara_shm(X) (spin_lock(&get_sara_shm_data((X))->lock))
#define unlock_sara_shm(X) (spin_unlock(&get_sara_shm_data((X))->lock))
-#endif
+
+static inline struct sara_inode_data *get_sara_inode_data(
+ const struct inode *inode)
+{
+ if (unlikely(!inode->i_security))
+ return NULL;
+ return inode->i_security + sara_blob_sizes.lbs_inode;
+}
+
+#define get_sara_inode_task(X) (get_sara_inode_data((X))->task)
+
+#endif /* CONFIG_SECURITY_SARA_WXPROT */
#endif /* __SARA_H */
diff --git a/security/sara/sara_data.c b/security/sara/sara_data.c
index 9afca37..e875cf0 100644
--- a/security/sara/sara_data.c
+++ b/security/sara/sara_data.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
static int sara_cred_prepare(struct cred *new, const struct cred *old,
@@ -40,15 +41,22 @@ static int sara_shm_alloc_security(struct kern_ipc_perm
*shp)
return 0;
}
+static void sara_task_to_inode(struct task_struct *t, struct inode *i)
+{
+ get_sara_inode_task(i) = t;
+}
+
static struct security_hook_list data_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(cred_prepare, sara_cred_prepare),
LSM_HOOK_INIT(cred_transfer, sara_cred_transfer),
LSM_HOOK_INIT(shm_alloc_security, sara_shm_alloc_security),
+ LSM_HOOK_INIT(task_to_inode, sara_task_to_inode),
};
struct lsm_blob_sizes sara_blob_sizes __lsm_ro_after_init = {
.lbs_cred = sizeof(struct sara_data),
.lbs_ipc = sizeof(struct sara_shm_data),
+ .lbs_inode = sizeof(struct sara_inode_data),
};
int __init sara_data_init(void)
diff --git a/security/sara/wxprot.c b/security/sara/wxprot.c
index 773d1fd..1a8d132 100644
--- a/security/sara/wxprot.c
+++ b/security/sara/wxprot.c
@@ -22,8 +22,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include
#include
@@ -615,6 +618,43 @@ static int sara_file_mprotect(struct vm_area_struct *vma,
return 0;
}
+static int sara_file_open(struct file *file)
+{
+ struct task_struct *t;
+ struct mm_struct *mm;
+ u16 sara_wxp_flags = get_current_sara_wxp_flags();
+
+ /*
+* Prevent write access to /proc/.../mem
+* if it operates on the mm_struct of the
+* current process: it could be used to
+* bypass W^X.
+*/
+
+ if (!sara_enabled ||
+ !wxprot_enabled ||
+ !(sara_wxp_flags & SARA_WXP_WXORX) ||
+ !(file->f_mode & FMODE_WRITE))
+ return 0;
+
+ t = get_sara_inode_task(file_inode(file));
+ if (unlikely(t != NULL &&
+strcmp(file->f_path.dentry->d_name.name,
+ "mem") == 0)) {
+ get_task_struct(t);
+ mm = get_task_mm(t);
+ put_task_struct(t);
+ if (unlikely(mm == current->mm))
+ sara_warn_or_goto(error,
+ "write access to /proc/*/mem");
+ mmput(mm);
+ }
+ return 0;
+error:
+ mmput(mm);
+ return -EACCES;
+}
+
#ifdef CONFIG_SECURITY_SARA_WXPROT_EMUTRAMP
static int sara_pagefault_handler(struct pt_regs *regs,
unsigned long error_code,
@@ -778,6 +818,7 @@ static int sara_setprocattr(const char *name, void *value,
size_t size)
LSM_HOOK_INIT(check_vmflags, sara_check_vmflags),
LSM_HOOK_INIT(shm_shmat, sara_shm_shmat),
LSM_HOOK_INIT(file_mprotect, sara_file_mprotect),
+ LSM_HOOK_INIT(file_open, sara_file_open),
#ifdef CONFIG_SECURITY_SARA_WXPROT_EMUTRAMP
LSM_HOOK_INIT(pagefault_handler, sara_pagefault_handler),
#endif
--
1.9.1
[PATCH v5 08/12] S.A.R.A.: trampoline emulation
Some programs need to generate part of their code at runtime. Luckily
enough, in some cases they only generate well-known code sequences (the
"trampolines") that can be easily recognized and emulated by the kernel.
This way WX Protection can still be active, so a potential attacker won't
be able to generate arbitrary sequences of code, but just those that are
explicitly allowed. This is not ideal, but it's still better than having WX
Protection completely disabled.
In particular S.A.R.A. is able to recognize trampolines used by GCC for
nested C functions and libffi's trampolines.
This feature is implemented only on x86_32 and x86_64.
Trampoline emulation is modified from Brad Spengler/PaX Team's code in the
last public patch of grsecurity/PaX based on my understanding of the code.
Changes or omissions from the original code are mine and don't reflect the
original grsecurity/PaX code.
Signed-off-by: Salvatore Mesoraca
---
arch/x86/Kbuild| 2 +
arch/x86/security/Makefile | 2 +
arch/x86/security/sara/Makefile| 1 +
arch/x86/security/sara/emutramp.c | 57
arch/x86/security/sara/trampolines32.h | 137 +++
arch/x86/security/sara/trampolines64.h | 164 +
security/sara/Kconfig | 18
security/sara/include/emutramp.h | 35 +++
security/sara/wxprot.c | 29 ++
9 files changed, 445 insertions(+)
create mode 100644 arch/x86/security/Makefile
create mode 100644 arch/x86/security/sara/Makefile
create mode 100644 arch/x86/security/sara/emutramp.c
create mode 100644 arch/x86/security/sara/trampolines32.h
create mode 100644 arch/x86/security/sara/trampolines64.h
create mode 100644 security/sara/include/emutramp.h
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 30dec01..4fea778 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -25,3 +25,5 @@ obj-y += platform/
obj-y += net/
obj-$(CONFIG_KEXEC_FILE) += purgatory/
+
+obj-y += security/
diff --git a/arch/x86/security/Makefile b/arch/x86/security/Makefile
new file mode 100644
index 000..ba4be4c
--- /dev/null
+++ b/arch/x86/security/Makefile
@@ -0,0 +1,2 @@
+subdir-$(CONFIG_SECURITY_SARA) += sara
+obj-$(CONFIG_SECURITY_SARA)+= sara/
diff --git a/arch/x86/security/sara/Makefile b/arch/x86/security/sara/Makefile
new file mode 100644
index 000..a4a76217
--- /dev/null
+++ b/arch/x86/security/sara/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SECURITY_SARA_WXPROT_EMUTRAMP) := emutramp.o
diff --git a/arch/x86/security/sara/emutramp.c
b/arch/x86/security/sara/emutramp.c
new file mode 100644
index 000..45122e5
--- /dev/null
+++ b/arch/x86/security/sara/emutramp.c
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * S.A.R.A. Linux Security Module
+ *
+ * Copyright (C) 2017 Salvatore Mesoraca
+ *
+ * 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.
+ *
+ * Assembly sequences used here were copied from
+ * PaX patch by PaX Team
+ * Being just hexadecimal constants, they are not subject to
+ * any copyright.
+ *
+ */
+
+#define PF_PROT(1 << 0)
+#define PF_USER(1 << 2)
+#define PF_INSTR (1 << 4)
+
+#ifdef CONFIG_X86_32
+
+#include "trampolines32.h"
+static inline int trampoline_emulator(struct pt_regs *regs,
+ unsigned long address)
+{
+ return sara_trampoline_emulator_x86_32(regs);
+}
+
+#else /* CONFIG_X86_32 */
+
+#include "trampolines64.h"
+static inline int trampoline_emulator(struct pt_regs *regs,
+ unsigned long address)
+{
+ return sara_trampoline_emulator_x86_64(regs, address);
+}
+
+#endif /* CONFIG_X86_32 */
+
+
+int sara_trampoline_emulator(struct pt_regs *regs,
+unsigned long error_code,
+unsigned long address)
+{
+ if (!(error_code & PF_USER) ||
+ !(error_code & PF_INSTR) ||
+ !(error_code & PF_PROT))
+ return 0;
+
+ local_irq_enable();
+ might_sleep();
+ might_fault();
+ return trampoline_emulator(regs, address);
+}
diff --git a/arch/x86/security/sara/trampolines32.h
b/arch/x86/security/sara/trampolines32.h
new file mode 100644
index 000..b3622d0
--- /dev/null
+++ b/arch/x86/security/sara/trampolines32.h
@@ -0,0 +1,137 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * S.A.R.A. Linux Security Module
+ *
+ * Copyright (C) 2017 Salvatore Mesoraca
+ *
+ * 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.
+ *
+ * Assembly sequences used here were copied from
+ * PaX patch by PaX Team
+ * Being just hexadecimal constants, they are
[PATCH v5 10/12] S.A.R.A.: XATTRs support
Adds support for extended filesystem attributes in security and user
namespaces. They can be used to override flags set via the centralized
configuration, even when S.A.R.A. configuration is locked or saractl
is not used at all.
Signed-off-by: Salvatore Mesoraca
---
Documentation/admin-guide/LSM/SARA.rst | 20 +
Documentation/admin-guide/kernel-parameters.txt | 16
include/uapi/linux/xattr.h | 4 +
security/sara/Kconfig | 22 ++
security/sara/wxprot.c | 99 +
5 files changed, 161 insertions(+)
diff --git a/Documentation/admin-guide/LSM/SARA.rst
b/Documentation/admin-guide/LSM/SARA.rst
index fdde04c..47d9364 100644
--- a/Documentation/admin-guide/LSM/SARA.rst
+++ b/Documentation/admin-guide/LSM/SARA.rst
@@ -55,6 +55,8 @@ WX Protection. In particular:
To extend the scope of the above features, despite the issues that they may
cause, they are complemented by **/proc/PID/attr/sara/wxprot** interface
and **trampoline emulation**.
+It's also possible to override the centralized configuration via `Extended
+filesystem attributes`_.
At the moment, WX Protection (unless specified otherwise) should work on
any architecture supporting the NX bit, including, but not limited to:
@@ -123,6 +125,24 @@ in your project or copy/paste parts of it.
To make things simpler `libsara` is the only part of S.A.R.A. released under
*CC0 - No Rights Reserved* license.
+Extended filesystem attributes
+^^
+When this functionality is enabled, it's possible to override
+WX Protection flags set in the main configuration via extended attributes,
+even when S.A.R.A.'s configuration is in "locked" mode.
+If the user namespace is also enabled, its attributes will override settings
+configured via the security namespace.
+The xattrs currently in use are:
+
+- security.sara.wxprot
+- user.sara.wxprot
+
+They can be manually set to the desired value as a decimal, hexadecimal or
+octal number. When this functionality is enabled, S.A.R.A. can be easily used
+without the help of its userspace tools. Though the preferred way to change
+these attributes is `sara-xattr` which is part of `saractl` [2]_.
+
+
Trampoline emulation
Some programs need to generate part of their code at runtime. Luckily enough,
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 3d6e86d..af40f1b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4254,6 +4254,22 @@
See S.A.R.A. documentation.
Default value is set via kernel config option.
+ sara.wxprot_xattrs_enabled= [SARA]
+ Enable support for security xattrs.
+ Format: { "0" | "1" }
+ See security/sara/Kconfig help text
+ 0 -- disable.
+ 1 -- enable.
+ Default value is set via kernel config option.
+
+ sara.wxprot_xattrs_user= [SARA]
+ Enable support for user xattrs.
+ Format: { "0" | "1" }
+ See security/sara/Kconfig help text
+ 0 -- disable.
+ 1 -- enable.
+ Default value is set via kernel config option.
+
serialnumber[BUGS=X86-32]
shapers=[NET]
diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
index c1395b5..45c0333 100644
--- a/include/uapi/linux/xattr.h
+++ b/include/uapi/linux/xattr.h
@@ -77,5 +77,9 @@
#define XATTR_POSIX_ACL_DEFAULT "posix_acl_default"
#define XATTR_NAME_POSIX_ACL_DEFAULT XATTR_SYSTEM_PREFIX
XATTR_POSIX_ACL_DEFAULT
+#define XATTR_SARA_SUFFIX "sara."
+#define XATTR_SARA_WXP_SUFFIX XATTR_SARA_SUFFIX "wxp"
+#define XATTR_NAME_SEC_SARA_WXP XATTR_SECURITY_PREFIX XATTR_SARA_WXP_SUFFIX
+#define XATTR_NAME_USR_SARA_WXP XATTR_USER_PREFIX XATTR_SARA_WXP_SUFFIX
#endif /* _UAPI_LINUX_XATTR_H */
diff --git a/security/sara/Kconfig b/security/sara/Kconfig
index 458e0e8..773256b 100644
--- a/security/sara/Kconfig
+++ b/security/sara/Kconfig
@@ -135,6 +135,28 @@ config SECURITY_SARA_WXPROT_EMUTRAMP
If unsure, answer y.
+config SECURITY_SARA_WXPROT_XATTRS_ENABLED
+ bool "xattrs support enabled by default."
+ depends on SECURITY_SARA_WXPROT
+ default n
+ help
+ If you say Y here it will be possible to override WX protection
+ configuration via extended attributes in the security namespace.
+ Even when S.A.R.A.'s configuration has been locked.
+
+ If unsure, answer N.
+
+config CONFIG_SECURITY_SARA_WXPROT_XATTRS_USER
+ bool "'user' namespace xattrs support enabled by default."
+ depends on SECURITY_SARA_WXPROT_XATTRS_ENABLED
+ default n
+
[PATCH v5 12/12] MAINTAINERS: take maintainership for S.A.R.A.
Signed-off-by: Salvatore Mesoraca --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f16e5d0..de6dab1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13925,6 +13925,15 @@ F: drivers/phy/samsung/phy-s5pv210-usb2.c F: drivers/phy/samsung/phy-samsung-usb2.c F: drivers/phy/samsung/phy-samsung-usb2.h +SARA SECURITY MODULE +M: Salvatore Mesoraca +T: git git://github.com/smeso/sara.git lsm/sara/master +W: https://sara.smeso.it +S: Maintained +F: security/sara/ +F: arch/x86/security/sara/ +F: Documentation/admin-guide/LSM/SARA.rst + SC1200 WDT DRIVER M: Zwane Mwaikambo S: Maintained -- 1.9.1
[PATCH v5 06/12] S.A.R.A.: WX protection
Introduction of S.A.R.A. WX Protection. It aims to improve user-space programs security by applying: - W^X enforcement - W!->X (once writable never executable) mprotect restriction - Executable MMAP prevention All of the above features can be enabled or disabled both system wide or on a per executable basis through the use of configuration. W^X enforcement works by blocking any memory allocation or mprotect invocation with both the WRITE and the EXEC flags enabled. W!->X restriction works by preventing any mprotect invocation that makes executable any page that is flagged VM_MAYWRITE. Additional restrictions are in place for System V shared memory segments: if a segment was attached as writable (executable) in the past it won't be allowed to be attached as executable (writable) in the future. This feature can be configured separately for stack, heap and other allocations. Executable MMAP prevention works by preventing any new executable allocation after the dynamic libraries have been loaded. It works under the assumption that, when the dynamic libraries have been finished loading, the RELRO section will be marked read only. Parts of WX Protection are inspired by some of the features available in PaX according to my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. Signed-off-by: Salvatore Mesoraca --- security/sara/Kconfig | 74 + security/sara/Makefile | 1 + security/sara/include/wxprot.h | 29 ++ security/sara/main.c | 6 + security/sara/wxprot.c | 679 + 5 files changed, 789 insertions(+) create mode 100644 security/sara/include/wxprot.h create mode 100644 security/sara/wxprot.c diff --git a/security/sara/Kconfig b/security/sara/Kconfig index b98cf27..54a96e0 100644 --- a/security/sara/Kconfig +++ b/security/sara/Kconfig @@ -60,3 +60,77 @@ config SECURITY_SARA_NO_RUNTIME_ENABLE If unsure, answer Y. +config SECURITY_SARA_WXPROT + bool "WX Protection: W^X and W!->X protections" + depends on SECURITY_SARA + default y + help + WX Protection aims to improve user-space programs security by applying: + - W^X memory restriction + - W!->X (once writable never executable) mprotect restriction + - Executable MMAP prevention + See Documentation/admin-guide/LSM/SARA.rst. for further information. + + If unsure, answer Y. + +choice + prompt "Default action for W^X and W!->X protections" + depends on SECURITY_SARA + depends on SECURITY_SARA_WXPROT + default SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_COMPLAIN_VERBOSE + +help + Choose the default behaviour of WX Protection when no config + rule matches or no rule is loaded. + For further information on available flags and their meaning + see Documentation/admin-guide/LSM/SARA.rst. + + config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_COMPLAIN_VERBOSE + bool "Protections enabled but not enforced." + help + All features enabled except "Executable MMAP prevention", + verbose reporting, but no actual enforce: it just complains. + Its numeric value is 0x3f, for more information see + Documentation/admin-guide/LSM/SARA.rst. + +config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_ENFORCE_VERBOSE + bool "Full protection, verbose." + help + All features enabled except "Executable MMAP prevention". + The enabled features will be enforced with verbose reporting. + Its numeric value is 0x2f, for more information see + Documentation/admin-guide/LSM/SARA.rst. + +config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_ENFORCE + bool "Full protection, quiet." + help + All features enabled except "Executable MMAP prevention". + The enabled features will be enforced quietly. + Its numeric value is 0xf, for more information see + Documentation/admin-guide/LSM/SARA.rst. + + config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_NONE + bool "No protection at all." + help + All features disabled. + Its numeric value is 0, for more information see + Documentation/admin-guide/LSM/SARA.rst. +endchoice + +config SECURITY_SARA_WXPROT_DISABLED + bool "WX protection will be disabled at boot." + depends on SECURITY_SARA_WXPROT + default n + help + If you say Y here WX protection won't be enabled at startup. You can + override this option via user-space utilities or at boot time via + "sara.wxprot_enabled=[0|1]" kernel parameter. + + If unsure, answer N. + +config SECURITY_SARA_WXPRO
Re: [PATCH v6 2/2] dt-bindings: net: bluetooth: Add device property firmware-name for QCA6174
Hi Rocky, > This patch adds an optional device property "firmware-name" to allow the > driver to load customized nvm firmware file based on this property. > > Signed-off-by: Rocky Liao > --- > Changes in v6: > * Added read firmware-name property for both QCA6174 and WCN399X > --- > Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt | 4 > 1 file changed, 4 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
[PATCH v5 03/12] S.A.R.A.: cred blob management
Creation of the S.A.R.A. cred blob management "API".
In order to allow S.A.R.A. to be stackable with other LSMs, it doesn't use
the "security" field of struct cred, instead it uses an ad hoc field named
security_sara.
This solution is probably not acceptable for upstream, so this part will
be modified as soon as the LSM stackable cred blob management will be
available.
Signed-off-by: Salvatore Mesoraca
---
security/sara/Makefile| 2 +-
security/sara/include/sara_data.h | 84 +++
security/sara/main.c | 7
security/sara/sara_data.c | 69
4 files changed, 161 insertions(+), 1 deletion(-)
create mode 100644 security/sara/include/sara_data.h
create mode 100644 security/sara/sara_data.c
diff --git a/security/sara/Makefile b/security/sara/Makefile
index 8acd291..14bf7a8 100644
--- a/security/sara/Makefile
+++ b/security/sara/Makefile
@@ -1,3 +1,3 @@
obj-$(CONFIG_SECURITY_SARA) := sara.o
-sara-y := main.o securityfs.o utils.o
+sara-y := main.o securityfs.o utils.o sara_data.o
diff --git a/security/sara/include/sara_data.h
b/security/sara/include/sara_data.h
new file mode 100644
index 000..9216c47
--- /dev/null
+++ b/security/sara/include/sara_data.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * S.A.R.A. Linux Security Module
+ *
+ * Copyright (C) 2017 Salvatore Mesoraca
+ *
+ * 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.
+ *
+ */
+
+#ifndef __SARA_DATA_H
+#define __SARA_DATA_H
+
+#include
+#include
+#include
+#include
+
+int sara_data_init(void) __init;
+
+extern struct lsm_blob_sizes sara_blob_sizes __lsm_ro_after_init;
+
+#ifdef CONFIG_SECURITY_SARA_WXPROT
+
+struct sara_data {
+ unsigned long relro_page;
+ struct file *relro_file;
+ u16 wxp_flags;
+ u16 execve_flags;
+ boolrelro_page_found;
+ boolmmap_blocked;
+};
+
+struct sara_shm_data {
+ boolno_exec;
+ boolno_write;
+ spinlock_t lock;
+};
+
+
+static inline struct sara_data *get_sara_data(const struct cred *cred)
+{
+ return cred->security + sara_blob_sizes.lbs_cred;
+}
+
+#define get_current_sara_data() get_sara_data(current_cred())
+
+#define get_sara_wxp_flags(X) (get_sara_data((X))->wxp_flags)
+#define get_current_sara_wxp_flags() get_sara_wxp_flags(current_cred())
+
+#define get_sara_execve_flags(X) (get_sara_data((X))->execve_flags)
+#define get_current_sara_execve_flags() get_sara_execve_flags(current_cred())
+
+#define get_sara_relro_page(X) (get_sara_data((X))->relro_page)
+#define get_current_sara_relro_page() get_sara_relro_page(current_cred())
+
+#define get_sara_relro_file(X) (get_sara_data((X))->relro_file)
+#define get_current_sara_relro_file() get_sara_relro_file(current_cred())
+
+#define get_sara_relro_page_found(X) (get_sara_data((X))->relro_page_found)
+#define get_current_sara_relro_page_found() \
+ get_sara_relro_page_found(current_cred())
+
+#define get_sara_mmap_blocked(X) (get_sara_data((X))->mmap_blocked)
+#define get_current_sara_mmap_blocked() get_sara_mmap_blocked(current_cred())
+
+
+static inline struct sara_shm_data *get_sara_shm_data(
+ const struct kern_ipc_perm *ipc)
+{
+ return ipc->security + sara_blob_sizes.lbs_ipc;
+}
+
+#define get_sara_shm_no_exec(X) (get_sara_shm_data((X))->no_exec)
+#define get_sara_shm_no_write(X) (get_sara_shm_data((X))->no_write)
+#define lock_sara_shm(X) (spin_lock(&get_sara_shm_data((X))->lock))
+#define unlock_sara_shm(X) (spin_unlock(&get_sara_shm_data((X))->lock))
+
+#endif
+
+#endif /* __SARA_H */
diff --git a/security/sara/main.c b/security/sara/main.c
index 52e6d18..dc5dda4 100644
--- a/security/sara/main.c
+++ b/security/sara/main.c
@@ -18,6 +18,7 @@
#include
#include "include/sara.h"
+#include "include/sara_data.h"
#include "include/securityfs.h"
static const int sara_version = SARA_VERSION;
@@ -93,6 +94,11 @@ static int __init sara_init(void)
goto error;
}
+ if (sara_data_init()) {
+ pr_crit("impossible to initialize creds.\n");
+ goto error;
+ }
+
pr_debug("initialized.\n");
if (sara_enabled)
@@ -112,4 +118,5 @@ static int __init sara_init(void)
.name = "sara",
.enabled = &sara_enabled,
.init = sara_init,
+ .blobs = &sara_blob_sizes,
};
diff --git a/security/sara/sara_data.c b/security/sara/sara_data.c
new file mode 100644
index 000..9afca37
--- /dev/null
+++ b/security/sara/sara_data.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * S.A.R.A. Linux Security Module
+ *
+ * Copyright (C) 2017 Salvatore Mesoraca
+ *
+ * This program is free software; you can redistribu
[PATCH v5 07/12] LSM: creation of "pagefault_handler" LSM hook
Creation of a new hook to let LSM modules handle user-space pagefaults on x86. It can be used to avoid segfaulting the originating process. If it's the case it can modify process registers before returning. This is not a security feature by itself, it's a way to soften some unwanted side-effects of restrictive security features. In particular this is used by S.A.R.A. to implement what PaX call "trampoline emulation" that, in practice, allows for some specific code sequences to be executed even if they are in non executable memory. This may look like a bad thing at first, but you have to consider that: - This allows for strict memory restrictions (e.g. W^X) to stay on even when they should be turned off. And, even if this emulation makes those features less effective, it's still better than having them turned off completely. - The only code sequences emulated are trampolines used to make function calls. In many cases, when you have the chance to make arbitrary memory writes, you can already manipulate the control flow of the program by overwriting function pointers or return values. So, in many cases, "trampoline emulation" doesn't introduce new exploit vectors. - It's a feature that can be turned on only if needed, on a per executable file basis. Signed-off-by: Salvatore Mesoraca --- arch/Kconfig | 6 ++ arch/x86/Kconfig | 1 + arch/x86/mm/fault.c | 6 ++ include/linux/lsm_hooks.h | 12 include/linux/security.h | 11 +++ security/security.c | 11 +++ 6 files changed, 47 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index c47b328..16997c3 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -252,6 +252,12 @@ config ARCH_HAS_FORTIFY_SOURCE config ARCH_HAS_KEEPINITRD bool +config ARCH_HAS_LSM_PAGEFAULT + bool + help + An architecture should select this if it supports + "pagefault_handler" LSM hook. + # Select if arch has all set_memory_ro/rw/x/nx() functions in asm/cacheflush.h config ARCH_HAS_SET_MEMORY bool diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 2bbbd4d..a3c7660 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -67,6 +67,7 @@ config X86 select ARCH_HAS_FORTIFY_SOURCE select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_HAS_KCOVif X86_64 + select ARCH_HAS_LSM_PAGEFAULT select ARCH_HAS_MEMBARRIER_SYNC_CORE select ARCH_HAS_PMEM_APIif X86_64 select ARCH_HAS_PTE_SPECIAL diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 46df4c6..7fe36f1 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -18,6 +18,7 @@ #include /* faulthandler_disabled() */ #include /* efi_recover_from_page_fault()*/ #include +#include /* security_pagefault_handler */ #include /* boot_cpu_has, ...*/ #include /* dotraplinkage, ... */ @@ -1360,6 +1361,11 @@ void do_user_addr_fault(struct pt_regs *regs, local_irq_enable(); } + if (unlikely(security_pagefault_handler(regs, + hw_error_code, + address))) + return; + perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address); if (hw_error_code & X86_PF_WRITE) diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 12ce609..478a187 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -518,6 +518,14 @@ * @vmflags contains the requested vmflags. * Return 0 if the operation is allowed to continue otherwise return * the appropriate error code. + * @pagefault_handler: + * Handle pagefaults on supported architectures, that is any architecture + * which defines CONFIG_ARCH_HAS_LSM_PAGEFAULT. + * @regs contains process' registers. + * @error_code contains error code for the pagefault. + * @address contains the address that caused the pagefault. + * Return 0 to let the kernel handle the pagefault as usually, any other + * value to let the process continue its execution. * @file_lock: * Check permission before performing file locking operations. * Note the hook mediates both flock and fcntl style locks. @@ -1603,6 +1611,9 @@ int (*file_mprotect)(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot); int (*check_vmflags)(vm_flags_t vmflags); + int (*pagefault_handler)(struct pt_regs *regs, +unsigned long error_code, +unsigned long address); int (*file_lock)(struct file *file, unsigned int cmd); int (*file_fcntl)(struct file *file, unsigned int cmd, unsigned long arg); @@ -1904,6 +1915,7 @@ struct securi
[PATCH v5 05/12] LSM: creation of "check_vmflags" LSM hook
Creation of a new LSM hook to check if a given configuration of vmflags,
for a new memory allocation request, should be allowed or not.
It's placed in "do_mmap", "do_brk_flags", "__install_special_mapping"
and "setup_arg_pages".
When loading an ELF, this hook is also used to determine what to do
with an RWE PT_GNU_STACK header. This allows LSM to force the loader
to silently ignore executable stack markings, which is useful a thing to
do when trampoline emulation is available.
Signed-off-by: Salvatore Mesoraca
---
fs/binfmt_elf.c | 3 ++-
fs/binfmt_elf_fdpic.c | 3 ++-
fs/exec.c | 4
include/linux/lsm_hooks.h | 7 +++
include/linux/security.h | 6 ++
mm/mmap.c | 13 +
security/security.c | 5 +
7 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 8264b46..1d98737 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -806,7 +806,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
for (i = 0; i < loc->elf_ex.e_phnum; i++, elf_ppnt++)
switch (elf_ppnt->p_type) {
case PT_GNU_STACK:
- if (elf_ppnt->p_flags & PF_X)
+ if (elf_ppnt->p_flags & PF_X &&
+ !security_check_vmflags(VM_EXEC|VM_READ|VM_WRITE))
executable_stack = EXSTACK_ENABLE_X;
else
executable_stack = EXSTACK_DISABLE_X;
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index d86ebd0d..6e0dee1 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -163,7 +163,8 @@ static int elf_fdpic_fetch_phdrs(struct elf_fdpic_params
*params,
if (phdr->p_type != PT_GNU_STACK)
continue;
- if (phdr->p_flags & PF_X)
+ if (phdr->p_flags & PF_X &&
+ !security_check_vmflags(VM_EXEC|VM_READ|VM_WRITE))
params->flags |= ELF_FDPIC_FLAG_EXEC_STACK;
else
params->flags |= ELF_FDPIC_FLAG_NOEXEC_STACK;
diff --git a/fs/exec.c b/fs/exec.c
index 89a500b..abf770a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -756,6 +756,10 @@ int setup_arg_pages(struct linux_binprm *bprm,
vm_flags |= mm->def_flags;
vm_flags |= VM_STACK_INCOMPLETE_SETUP;
+ ret = security_check_vmflags(vm_flags);
+ if (ret)
+ goto out_unlock;
+
ret = mprotect_fixup(vma, &prev, vma->vm_start, vma->vm_end,
vm_flags);
if (ret)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 47f58cf..12ce609 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -513,6 +513,11 @@
* @reqprot contains the protection requested by the application.
* @prot contains the protection that will be applied by the kernel.
* Return 0 if permission is granted.
+ * @check_vmflags:
+ * Check if the requested @vmflags are allowed.
+ * @vmflags contains the requested vmflags.
+ * Return 0 if the operation is allowed to continue otherwise return
+ * the appropriate error code.
* @file_lock:
* Check permission before performing file locking operations.
* Note the hook mediates both flock and fcntl style locks.
@@ -1597,6 +1602,7 @@
unsigned long prot, unsigned long flags);
int (*file_mprotect)(struct vm_area_struct *vma, unsigned long reqprot,
unsigned long prot);
+ int (*check_vmflags)(vm_flags_t vmflags);
int (*file_lock)(struct file *file, unsigned int cmd);
int (*file_fcntl)(struct file *file, unsigned int cmd,
unsigned long arg);
@@ -1897,6 +1903,7 @@ struct security_hook_heads {
struct hlist_head mmap_addr;
struct hlist_head mmap_file;
struct hlist_head file_mprotect;
+ struct hlist_head check_vmflags;
struct hlist_head file_lock;
struct hlist_head file_fcntl;
struct hlist_head file_set_fowner;
diff --git a/include/linux/security.h b/include/linux/security.h
index 659071c..aed78eb 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -312,6 +312,7 @@ int security_mmap_file(struct file *file, unsigned long
prot,
int security_mmap_addr(unsigned long addr);
int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot,
unsigned long prot);
+int security_check_vmflags(vm_flags_t vmflags);
int security_file_lock(struct file *file, unsigned int cmd);
int security_file_fcntl(struct file *file, unsigned int cmd, unsigned long
arg);
void security_file_set_fowner(struct file *file);
@@ -859,6 +860,11 @@ static inline int security_file_mprotect(struct
vm_area_struct *vma,
return 0;
}
+static inline int security_check_vmflags(vm_flags_
[PATCH v5 04/12] S.A.R.A.: generic DFA for string matching
Creation of a generic Discrete Finite Automata implementation
for string matching. The transition tables have to be produced
in user-space.
This allows us to possibly support advanced string matching
patterns like regular expressions, but they need to be supported
by user-space tools.
Signed-off-by: Salvatore Mesoraca
---
security/sara/Kconfig| 22 +++
security/sara/Makefile | 3 +-
security/sara/dfa.c | 335 +++
security/sara/dfa_test.c | 135
security/sara/include/dfa.h | 52 ++
security/sara/include/dfa_test.h | 29
security/sara/main.c | 6 +
7 files changed, 581 insertions(+), 1 deletion(-)
create mode 100644 security/sara/dfa.c
create mode 100644 security/sara/dfa_test.c
create mode 100644 security/sara/include/dfa.h
create mode 100644 security/sara/include/dfa_test.h
diff --git a/security/sara/Kconfig b/security/sara/Kconfig
index 0456220..b98cf27 100644
--- a/security/sara/Kconfig
+++ b/security/sara/Kconfig
@@ -13,6 +13,28 @@ menuconfig SECURITY_SARA
If unsure, answer N.
+config SECURITY_SARA_DFA_32BIT
+ bool "Use 32 bits instead of 16 bits for DFA states' id"
+ depends on SECURITY_SARA
+ default n
+ help
+ If you say Y here S.A.R.A. will use more memory, but you will be
+ able to configure more rules.
+ See Documentation/admin-guide/LSM/SARA.rst. for further information.
+
+ If unsure, answer N.
+
+config SECURITY_SARA_DFA_TEST
+ bool "Enable test interface for the internal DFA engine"
+ depends on SECURITY_SARA
+ default n
+ help
+ If you say Y here S.A.R.A. will enable a user-space interface
+ that can be used to test the DFA engine (e.g. via `saractl test`).
+ See Documentation/admin-guide/LSM/SARA.rst. for further information.
+
+ If unsure, answer N.
+
config SECURITY_SARA_DEFAULT_DISABLED
bool "S.A.R.A. will be disabled at boot."
depends on SECURITY_SARA
diff --git a/security/sara/Makefile b/security/sara/Makefile
index 14bf7a8..ffa1be1 100644
--- a/security/sara/Makefile
+++ b/security/sara/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_SECURITY_SARA) := sara.o
-sara-y := main.o securityfs.o utils.o sara_data.o
+sara-y := main.o securityfs.o utils.o sara_data.o dfa.o
+sara-$(CONFIG_SECURITY_SARA_DFA_TEST) += dfa_test.o
diff --git a/security/sara/dfa.c b/security/sara/dfa.c
new file mode 100644
index 000..e39b27e
--- /dev/null
+++ b/security/sara/dfa.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * S.A.R.A. Linux Security Module
+ *
+ * Copyright (C) 2017 Salvatore Mesoraca
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "include/sara.h"
+#include "include/dfa.h"
+#include "include/securityfs.h"
+
+#define DFA_MAGIC_SIZE 8
+#define DFA_MAGIC "SARADFAT"
+
+#define DFA_INPUTS 255
+
+#ifndef CONFIG_SECURITY_SARA_DFA_32BIT
+#define pr_err_dfa_size() \
+ pr_err_ratelimited("DFA: too many states. Recompile kernel with
CONFIG_SARA_DFA_32BIT.\n")
+#else
+#define pr_err_dfa_size() pr_err_ratelimited("DFA: too many states.\n")
+#endif
+
+void sara_dfa_free_tables(struct sara_dfa_tables *dfa)
+{
+ if (dfa) {
+ kvfree(dfa->output);
+ kvfree(dfa->def);
+ kvfree(dfa->base);
+ kvfree(dfa->next);
+ kvfree(dfa->check);
+ kvfree(dfa);
+ }
+}
+
+static struct sara_dfa_tables *sara_dfa_alloc_tables(sara_dfa_state states,
+sara_dfa_state cmp_states)
+{
+ struct sara_dfa_tables *tmp = NULL;
+
+ tmp = kvzalloc(sizeof(*tmp), GFP_KERNEL_ACCOUNT);
+ if (!tmp)
+ goto err;
+ tmp->output = kvcalloc(states,
+ sizeof(*tmp->output),
+ GFP_KERNEL_ACCOUNT);
+ if (!tmp->output)
+ goto err;
+ tmp->def = kvcalloc(states,
+ sizeof(*tmp->def),
+ GFP_KERNEL_ACCOUNT);
+ if (!tmp->def)
+ goto err;
+ tmp->base = kvcalloc(states,
+sizeof(*tmp->base),
+GFP_KERNEL_ACCOUNT);
+ if (!tmp->base)
+ goto err;
+ tmp->next = kvcalloc(cmp_states,
+sizeof(*tmp->next) * DFA_INPUTS,
+GFP_KERNEL_ACCOUNT);
+ if (!tmp->next)
+ goto err;
+ tmp->check = kvcalloc(cmp_states,
+ sizeof(*tmp->check) * DFA_INPUTS,
+ GFP_KERNEL_ACCOUNT);
+ if (!tmp->check)
+ goto err;
+
Re: [PATCH] Bluetooth: btbcm: Add entry for BCM4359C0 UART bluetooth
Hi Neil, > The BCM4359C0 BT/Wi-Fi compo chip needs an entry to be discovered > by the btbcm driver. > > Tested using an AP6398S module from Ampak. > > Signed-off-by: Neil Armstrong > --- > drivers/bluetooth/btbcm.c | 1 + > 1 file changed, 1 insertion(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v1 0/4] add boot-gpios and clock property to btmtkuart
Hi Sean, > Update dt-binding and the corresponding implmentation of boot-gpios and clock > property to btmtkuart. > > Sean Wang (4): > dt-bindings: net: bluetooth: add boot-gpios property to UART-based >device > dt-bindings: net: bluetooth: add clock property to UART-based device > Bluetooth: btmtkuart: add an implementation for boot-gpios property > Bluetooth: btmtkuart: add an implementation for clock osc property > > .../bindings/net/mediatek-bluetooth.txt | 17 +++ > drivers/bluetooth/btmtkuart.c | 51 +++ > 2 files changed, 58 insertions(+), 10 deletions(-) all four patches have been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] Bluetooth: hci_bcsp: Fix memory leak in rx_skb
Hi Tomas, > Syzkaller found that it is possible to provoke a memory leak by > never freeing rx_skb in struct bcsp_struct. > > Fix by freeing in bcsp_close() > > Signed-off-by: Tomas Bortoli > Reported-by: syzbot+98162c885993b72f1...@syzkaller.appspotmail.com > --- > drivers/bluetooth/hci_bcsp.c | 4 > 1 file changed, 4 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] Bluetooth: Add new 13d3:3501 QCA_ROME device
Hi Joao Paulo, > Without the QCA ROME setup routine this adapter fails to establish a SCO > connection. > > T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3501 Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > Signed-off-by: João Paulo Rechi Vita > --- > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] Bluetooth: Add new 13d3:3491 QCA_ROME device
Hi Joao Paulo, > Without the QCA ROME setup routine this adapter fails to establish a SCO > connection. > > T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3491 Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > Signed-off-by: João Paulo Rechi Vita > --- > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) Patch has been applied to bluetooth-next tree. Regards Marcel
Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
On Saturday, July 6, 2019 10:17:15 AM CEST Rafael J. Wysocki wrote:
> On Fri, Jul 5, 2019 at 7:22 PM Thomas Lindroth
> wrote:
> >
> > On recent kernels the tick remains active on idle adaptive-tick CPUs when a
> > small
> > value is written to /dev/cpu_dma_latency to restrict the highest C-state.
> > Before the
> > idle loop redesign in 4.17 idle CPUs had the tick disabled even when
> > C-state were
> > restricted. Is this change intentional or a regression?
>
> It was intentional, but this kind of is a gray area.
>
> At least for the menu governor you may argue that the decision on
> whether or not to stop the tick should be based on the predicted idle
> duration.
But also see below.
> > I use an x86_64 system built with CONFIG_NO_HZ_FULL that I recently
> > upgraded to the 4.19 series from the 4.14 series.
> > I noticed that adaptive-tick CPUs (nohz_full=1-7) still fire timer
> > interrupts about 1000 times/s (CONFIG_HZ_1000=y) even
> > when they are mostly idle. Some debugging showed that this only happens
> > when a program is writing to
> > /dev/cpu_dma_latency to restrict C-states. The old 4.14 kernel only have
> > around 10 timer interrupts per second on idle
> > adaptive-tick CPU even when C-states are restricted that way.
> >
> > I would expect an adaptive-tick CPU to turn off the tick when it has 0 or 1
> > processes to run and enable the tick for >2
> > processes. Kernels after 4.17 instead have the tick on when 0 or >2
> > processes are running and the tick off in the 1 process
> > case. Since the tick is off when a single process is running that workload
> > isn't directly harmed by the change but if the CPU
> > use hyperthreading the constant wakeups on an idle HT sibling will reduce
> > performance on the other sibling.
So it looks like the idle loop needs a special case for adaptive-tick CPUs.
> >
> > They way I look for timer interrupts is by comparing the LOC line in
> > /proc/interrupts or using the hrtimer_expire_entry
> > tracepoint when function=tick_sched_timer. Both methods seem to give the
> > same results.
> >
> > I can reproduce the problem using an i7-4790K CPU with
> > /sys/devices/system/cpu/cpuidle/current_driver:intel_idle. I can
> > also reproduce the problem on an old core2duo laptop with
> > current_driver:acpi_idle but I can't reproduce the problem
> > in a virtual machine where current_driver:none. I also can't reproduce the
> > problem if C-states are restricted using the
> > intel_idle.max_cstate=1 kernel argument instead of /dev/cpu_dma_latency.
> >
> > The commit that introduced the change is 554c8aa8ec "sched: idle: Select
> > idle state before stopping the tick" in v4.17
> > and the problem exists at least up to kernel 5.1 using the menu cpuidle
> > governor.
>
> Restoring the previous behavior in this case should be relatively
> straightforward. I'll send you a patch to do that later.
The patch is below, but note that it adds the tick stopping overhead to the
idle loop
for CPUs that are not adaptive-tick and when PM QoS latency constraints are used
which is not desirable in general.
Please test it, but as I said above, the real solution appears to be to treat
adaptive-tick
CPUs in a special way in the idle loop.
---
drivers/cpuidle/governors/menu.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -302,9 +302,10 @@ static int menu_select(struct cpuidle_dr
!drv->states[0].disabled && !dev->states_usage[0].disable)) {
/*
* In this case state[0] will be used no matter what, so return
-* it right away and keep the tick running.
+* it right away and keep the tick running if state[0] is a
+* polling one.
*/
- *stop_tick = false;
+ *stop_tick = !!(drv->states[0].flags & CPUIDLE_FLAG_POLLING);
return 0;
}
@@ -395,16 +396,9 @@ static int menu_select(struct cpuidle_dr
return idx;
}
- if (s->exit_latency > latency_req) {
- /*
-* If we break out of the loop for latency reasons, use
-* the target residency of the selected state as the
-* expected idle duration so that the tick is retained
-* as long as that target residency is low enough.
-*/
- predicted_us = drv->states[idx].target_residency;
+ if (s->exit_latency > latency_req)
break;
- }
+
idx = i;
}
Re: [PATCH v2 5/7] x86/mm, tracing: Fix CR2 corruption
On 2019/07/05 11:18, Linus Torvalds wrote:
> On Fri, Jul 5, 2019 at 5:03 AM Peter Zijlstra wrote:
>>
>> Despire the current efforts to read CR2 before tracing happens there
>> still exist a number of possible holes:
>
> So this whole series disturbs me for the simple reason that I thought
> tracing was supposed to save/restore cr2 and make it unnecessary to
> worry about this in non-tracing code.
>
> That is very much what the NMI code explicitly does. Why shouldn't all
> the other tracing code do the same thing in case they can take page
> faults?
>
> So I don't think the patches are wrong per se, but this seems to solve
> it at the wrong level.
>
> Linus
>
Steven previously tried to fix it by saving CR2 in TRACE_IRQS_OFF:
https://lore.kernel.org/lkml/20190320221534.165ab...@oasis.local.home/
But hit the following WARNING:
https://lore.kernel.org/lkml/20190321095502.47b51...@gandalf.local.home/
I tried to find out the root cause of the WARNING, and found that it is
caused by touching trace point(TRACE_IRQS_OFF) before search_binary_handler()
at exeve.
To prevent userstack trace code from reading user stack before it becomes ready,
checking current->in_execve in stack_trace_save_user() can help Steven's
approach,
though trace_sched_process_exec() is called before current->in_execve = 0 so it
changes
current behavior.
The PoC code is as follows:
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 2abf27d7df6b..30fa6e1b7a87 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -116,10 +116,12 @@ void arch_stack_walk_user(stack_trace_consume_fn
consume_entry, void *cookie,
const struct pt_regs *regs)
{
const void __user *fp = (const void __user *)regs->bp;
+ unsigned long address;
if (!consume_entry(cookie, regs->ip, false))
return;
+ address = read_cr2();
while (1) {
struct stack_frame_user frame;
@@ -131,11 +133,14 @@ void arch_stack_walk_user(stack_trace_consume_fn
consume_entry, void *cookie,
break;
if (frame.ret_addr) {
if (!consume_entry(cookie, frame.ret_addr, false))
- return;
+ break;
}
if (fp == frame.next_fp)
break;
fp = frame.next_fp;
}
+
+ if (address != read_cr2())
+ write_cr2(address);
}
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index 36139de0a3c4..489d33bb5d28 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -230,6 +230,9 @@ unsigned int stack_trace_save_user(unsigned long *store,
unsigned int size)
/* Trace user stack if not a kernel thread */
if (!current->mm)
return 0;
+ /* current can reach some trace points before its stack is ready */
+ if (current->in_execve)
+ return 0;
arch_stack_walk_user(consume_entry, &c, task_pt_regs(current));
return c.len;
Re: [PATCH 1/2] regulator: axp20x: fix DCDCA and DCDCD for AXP806
On Sat, Jul 06, 2019 at 12:05:44PM +0200, Jernej Skrabec wrote: > Refactoring of the driver introduced few bugs in AXP806's DCDCA and > DCDCD regulator definitions. This is not a great changelog - what are the bugs and how does this patch fix them? signature.asc Description: PGP signature
[PATCH] ipc/sem: Three function calls less in do_semtimedop()
From: Markus Elfring
Date: Sat, 6 Jul 2019 14:16:24 +0200
Avoid three function calls by using ternary operators instead of
conditional statements.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
ipc/sem.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 7da4504bcc7c..56ea549ac270 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -2122,27 +2122,18 @@ static long do_semtimedop(int semid, struct sembuf
__user *tsops,
int idx = array_index_nospec(sops->sem_num, sma->sem_nsems);
curr = &sma->sems[idx];
- if (alter) {
- if (sma->complex_count) {
- list_add_tail(&queue.list,
- &sma->pending_alter);
- } else {
-
- list_add_tail(&queue.list,
- &curr->pending_alter);
- }
- } else {
- list_add_tail(&queue.list, &curr->pending_const);
- }
+ list_add_tail(&queue.list,
+ alter
+ ? (sma->complex_count
+ ? &sma->pending_alter
+ : &curr->pending_alter)
+ : &curr->pending_const);
} else {
if (!sma->complex_count)
merge_queues(sma);
- if (alter)
- list_add_tail(&queue.list, &sma->pending_alter);
- else
- list_add_tail(&queue.list, &sma->pending_const);
-
+ list_add_tail(&queue.list,
+ alter ? &sma->pending_alter :
&sma->pending_const);
sma->complex_count++;
}
--
2.22.0
Re: [PATCH 1/2] regulator: axp20x: fix DCDCA and DCDCD for AXP806
Dne sobota, 06. julij 2019 ob 13:21:44 CEST je Mark Brown napisal(a): > On Sat, Jul 06, 2019 at 12:05:44PM +0200, Jernej Skrabec wrote: > > Refactoring of the driver introduced few bugs in AXP806's DCDCA and > > DCDCD regulator definitions. > > This is not a great changelog - what are the bugs and how does > this patch fix them? In case of DCDCA, number of steps for second range should be 20 (0x14), but it was set to 14. So I guess patch author missed "0x". Currently, math doesn't work, because sum of both number of steps plus 2 must be equal to number of voltages macro. Same error is present in AXP803 DCDC6 regulator. In case of DCDCD, array of ranges (axp806_dcdcd_ranges) contains two ranges, which use same start and end macros. By checking datasheet or just checking macros at the top of the source file, it's obvious that "1" is missing in second range macro names (1600 instead of 600). And I think I found another bug, AXP803_DCDC5_NUM_VOLTAGES should be 69 and not 68. However, this bug was present before refactoring, refactoring just carried it over. Best regards, Jernej
Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used
On 7/6/19 1:06 PM, Rafael J. Wysocki wrote:
The patch is below, but note that it adds the tick stopping overhead to the
idle loop
for CPUs that are not adaptive-tick and when PM QoS latency constraints are used
which is not desirable in general.
Please test it, but as I said above, the real solution appears to be to treat
adaptive-tick
CPUs in a special way in the idle loop.
---
drivers/cpuidle/governors/menu.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -302,9 +302,10 @@ static int menu_select(struct cpuidle_dr
!drv->states[0].disabled && !dev->states_usage[0].disable)) {
/*
* In this case state[0] will be used no matter what, so return
-* it right away and keep the tick running.
+* it right away and keep the tick running if state[0] is a
+* polling one.
*/
- *stop_tick = false;
+ *stop_tick = !!(drv->states[0].flags & CPUIDLE_FLAG_POLLING);
return 0;
}
@@ -395,16 +396,9 @@ static int menu_select(struct cpuidle_dr
return idx;
}
- if (s->exit_latency > latency_req) {
- /*
-* If we break out of the loop for latency reasons, use
-* the target residency of the selected state as the
-* expected idle duration so that the tick is retained
-* as long as that target residency is low enough.
-*/
- predicted_us = drv->states[idx].target_residency;
+ if (s->exit_latency > latency_req)
break;
- }
+
idx = i;
}
I tested the patch and it appears to work. Idle CPUs now have ticks disabled
even
when /dev/cpu_dma_latency is used.
I also want to thank you for your work on the idle loop redesign. Overall it
works
much better than before. I used to have a problem where idle CPUs would end up
doing C0 polling for a long time resulting in a big performance drop on the HT
sibling. When benchmarking I always had to offline siblings to get consistent
results. That problem was fixed in the redesign.
Re: [PATCH 0/3] Marvell HCI fixes and serdev support
Hallo Sascha, > First two patches are a fix for the Marvell HCI driver which fails to > properly upload the firmware. Third patch adds simple serdev support > to the driver. > > Sascha > > Sascha Hauer (3): > Bluetooth: hci_ldisc: Add function to wait for characters to be sent > Bluetooth: hci_mrvl: Wait for final ack before switching baudrate > Bluetooth: hci_mrvl: Add serdev support > > .../bindings/net/marvell-bluetooth.txt| 25 +++ > drivers/bluetooth/Kconfig | 1 + > drivers/bluetooth/hci_ldisc.c | 8 +++ > drivers/bluetooth/hci_mrvl.c | 72 ++- > drivers/bluetooth/hci_uart.h | 1 + > 5 files changed, 106 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/net/marvell-bluetooth.txt all 4 patches have been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] i2c: tegra: Add Dmitry as a reviewer
05.07.2019 21:49, Wolfram Sang пишет: > On Sun, Jun 23, 2019 at 08:46:55PM +0300, Dmitry Osipenko wrote: >> I'm contributing to Tegra's upstream development in general and happened >> to review the Tegra's I2C patches for awhile because I'm actively using >> upstream kernel on all of my Tegra-powered devices and initially some of >> the submitted patches were getting my attention since they were causing >> problems. Recently Wolfram Sang asked whether I'm interested in becoming >> a reviewer for the driver and I don't mind at all. >> >> Signed-off-by: Dmitry Osipenko > > Applied to for-current with a comment that Thierry acked this in the > mail thread prior this patch. Thanks! > Awesome, thank you very much!
RE: linux-next: build failure after merge of the slave-dma tree
Hi Stephen,
That's caused by 'of_irq_count' NOT export to global symbol, and I'm
curious why it has been
here for so long since Zhangfei found it in 2015.
https://patchwork.kernel.org/patch/7404681/
Hi Rob,
Is there something I miss so that Zhangfei's patch not accepted finally?
On 04-07-19, 15:31 Stephen Rothwell wrote:
> Hi all,
>
> After merging the slave-dma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "of_irq_count" [drivers/dma/fsl-edma.ko] undefined!
>
> Caused by commit
>
> 7144afd025b2 ("dmaengine: fsl-edma: add i.mx7ulp edma2 version
> support")
>
> I have reverted that commit for today.
>
> --
> Cheers,
> Stephen Rothwell
[PATCH] sched/topology: One function call less in build_group_from_child_sched_domain()
From: Markus Elfring Date: Sat, 6 Jul 2019 16:00:13 +0200 Avoid an extra function call by using a ternary operator instead of a conditional statement. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- kernel/sched/topology.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index f751ce0b783e..6190eb52c30a 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -886,11 +886,7 @@ build_group_from_child_sched_domain(struct sched_domain *sd, int cpu) return NULL; sg_span = sched_group_span(sg); - if (sd->child) - cpumask_copy(sg_span, sched_domain_span(sd->child)); - else - cpumask_copy(sg_span, sched_domain_span(sd)); - + cpumask_copy(sg_span, sched_domain_span(sd->child ? sd->child : sd)); atomic_inc(&sg->ref); return sg; } -- 2.22.0
Re: [PATCH] kallsyms: exclude kasan local symbols on s390
On Sat, Jun 29, 2019 at 2:22 AM Vasily Gorbik wrote: > > gcc asan instrumentation emits the following sequence to store frame pc > when the kernel is built with CONFIG_RELOCATABLE: > debug/vsprintf.s: > .section.data.rel.ro.local,"aw" > .align 8 > .LC3: > .quad .LASANPC4826@GOTOFF > .text > .align 8 > .type number, @function > number: > .LASANPC4826: > > and in case reloc is issued for LASANPC label it also gets into .symtab > with the same address as actual function symbol: > $ nm -n vmlinux | grep 01397150 > 01397150 t .LASANPC4826 > 01397150 t number > > In the end kernel backtraces are almost unreadable: > [ 143.748476] Call Trace: > [ 143.748484] ([<2da3e62c>] .LASANPC2671+0x114/0x190) > [ 143.748492] [<2eca1a58>] .LASANPC2612+0x110/0x160 > [ 143.748502] [<2de9d830>] print_address_description+0x80/0x3b0 > [ 143.748511] [<2de9dd64>] __kasan_report+0x15c/0x1c8 > [ 143.748521] [<2ecb56d4>] strrchr+0x34/0x60 > [ 143.748534] [<03ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan] > [ 143.748547] [<03ff800a9bba>] kmalloc_tests_init+0xe2/0x528 > [test_kasan] > [ 143.748555] [<2da2117c>] .LASANPC4069+0x354/0x748 > [ 143.748563] [<2dbfbb16>] do_init_module+0x136/0x3b0 > [ 143.748571] [<2dbff3f4>] .LASANPC3191+0x2164/0x25d0 > [ 143.748580] [<2dbffc4c>] .LASANPC3196+0x184/0x1b8 > [ 143.748587] [<2ecdf2ec>] system_call+0xd8/0x2d8 > > Since LASANPC labels are not even unique and get into .symtab only due > to relocs filter them out in kallsyms. > > Signed-off-by: Vasily Gorbik Applied to linux-kbuild. Thanks. > --- > scripts/kallsyms.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c > index e17837f1d3f2..ae6504d07fd6 100644 > --- a/scripts/kallsyms.c > +++ b/scripts/kallsyms.c > @@ -150,6 +150,9 @@ static int read_symbol(FILE *in, struct sym_entry *s) > /* exclude debugging symbols */ > else if (stype == 'N' || stype == 'n') > return -1; > + /* exclude s390 kasan local symbols */ > + else if (!strncmp(sym, ".LASANPC", 8)) > + return -1; > > /* include the type field in the symbol name, so that it gets > * compressed together */ > -- > 2.21.0 > -- Best Regards Masahiro Yamada
Re: [PATCH] kbuild: add more hints about SUBDIRS replacement
On Wed, Jun 26, 2019 at 11:30 PM Sam Ravnborg wrote:
>
> On Tue, Jun 25, 2019 at 05:51:27PM +0900, Masahiro Yamada wrote:
> > Commit 0126be38d988 ("kbuild: announce removal of SUBDIRS if used")
> > added a hint about the 'SUBDIRS' replacement, but it was not clear
> > enough.
> >
> > Multiple people sent me similar questions, patches.
> >
> > https://lkml.org/lkml/2019/1/17/456
> >
> > I did not mean to suggest M= for building a subdirectory in the kernel
> > tree.
> >
> > >From the commit 669efc76b317 ("net: hns3: fix compile error"), people
> > already (ab)use M=... to do that because it seems to work to some extent.
> >
> > Documentation/kbuild/kbuild.txt says M= and KBUILD_EXTMOD are used for
> > building external modules.
> >
> > In fact, Kbuild supports the single target '%/' for this purpose, but
> > this may not be noticed much.
> >
> > Kindly add more hints.
> >
> > Makefile:213: = WARNING
> > Makefile:214: 'SUBDIRS' will be removed after Linux 5.3
> > Makefile:215:
> > Makefile:216: If you are building an individual subdirectory
> > Makefile:217: in the kernel tree, you can do like this:
> > Makefile:218: $ make path/to/dir/you/want/to/build/
> > Makefile:219: (Do not forget the trailing slash)
> > Makefile:220:
> > Makefile:221: If you are building an external module,
> > Makefile:222: Please use 'M=' or 'KBUILD_EXTMOD' instead
> > Makefile:223: ==
> >
> > Suggested-by: Christoph Hellwig
> > Signed-off-by: Masahiro Yamada
>
> Nice!
>
> Acked-by: Sam Ravnborg
>
> Sam
Applied to linux-kbuild.
--
Best Regards
Masahiro Yamada
Re: linux-next: Tree for Jul 4
On Sat, Jul 06, 2019 at 08:17:29PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Sat, 6 Jul 2019 11:46:47 +0200 Greg Kroah-Hartman
> wrote:
> >
> > On Sat, Jul 06, 2019 at 07:44:12PM +1000, Stephen Rothwell wrote:
> > >
> > > On Sat, 6 Jul 2019 10:34:33 +0200 Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:
> > > > >
> > > > > This release produces a whole lot (over 200) of this message in my
> > > > > qemu
> > > > > boot tests:
> > > > >
> > > > > [1.698497] debugfs: File 'sched' already present!
> > > > >
> > > > > Introduced by commit
> > > > >
> > > > > 43e23b6c0b01 ("debugfs: log errors when something goes wrong")
> > > > >
> > > > > from the driver-core tree. I assume that the error(?) was already
> > > > > happening, but it is now being reported.
> > > >
> > > > What are you passing to qemu to get this? I just tried it myself and
> > > > see no error reports at all. Have a .config I can use to try to
> > > > reproduce this?
> > >
> > > It is a powerpc pseries_le_defconfig kernel and I run qemu like this:
> > >
> > > qemu-system-ppc64 -M pseries -m 2G -vga none -nographic -kernel vmlinux
> > > -initrd rootfs.cpio.gz
> >
> > Hm, I think my rootfs initrd might be quite simple compared to yours (it
> > drops me into a busybox shell). Any pointers to where you created yours
> > from?
>
> Michael Ellerman gave it to me. It is very simple. Its /init is just
>
> $ cat init
> #!/bin/sh
> # devtmpfs does not get automounted for initramfs
> /bin/mount -t devtmpfs devtmpfs /dev
> exec 0 exec 1>/dev/console
> exec 2>/dev/console
> exec /sbin/init $*
>
> and /sbin/init is a link to /bin/busybox
>
> It is all run by an expect script that just waits for the login:
> prompt, logs in a root and runs "halt".
>
> All the debugfs messages appear before the kernel finished booting.
Thanks, this helped. Looks like it is the loop device causing this. Or
at least I can trigger it here with that module.
And it seems that the debugfs code for those devices never worked, let
me unwind the mess of pointers to try to find the real solution here...
thanks,
greg k-h
Re: [PATCH v5 00/12] S.A.R.A. a new stacked LSM
On Saturday, July 6, 2019 10:54 AM, Salvatore Mesoraca wrote: > S.A.R.A. is meant to be stacked but it needs cred blobs and the procattr > interface, so I temporarily implemented those parts in a way that won't > be acceptable for upstream, but it works for now. I know that there > is some ongoing work to make cred blobs and procattr stackable, as soon > as the new interfaces will be available I'll reimplement the involved > parts. I thought all stacking pieces for minor LSM were merged in Linux 5.1. Is there still something missing or is this comment out-fo-date? Jordan
[GIT PULL] dmaengine fixes for 5.2
Hi Linus, Couple for fixes came for dmaengine drivers. One fixes a patch in 5.2-rc1 and others and cced stable. Please pull to receive: The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) are available in the Git repository at: git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-fix-5.2 for you to fetch changes up to f6034225442c4a87906d36e975fd9e99a8f95487: dmaengine: qcom: bam_dma: Fix completed descriptors count (2019-07-05 13:18:27 +0530) dmaengine fixes for v5.2 The fixes for 5.2 are: - bam_dma fix for completed descriptor count - fix for imx-sdma remove BD_INTR for channel0 and use-after-free on probe error path - endian bug fix in jz4780 IRQ handler Dan Carpenter (1): dmaengine: jz4780: Fix an endian bug in IRQ handler Robin Gong (1): dmaengine: imx-sdma: remove BD_INTR for channel0 Sricharan R (1): dmaengine: qcom: bam_dma: Fix completed descriptors count Sven Van Asbroeck (1): dmaengine: imx-sdma: fix use-after-free on probe error path drivers/dma/dma-jz4780.c | 5 +++-- drivers/dma/imx-sdma.c | 52 ++ drivers/dma/qcom/bam_dma.c | 3 +++ 3 files changed, 35 insertions(+), 25 deletions(-) Thanks -- ~Vinod signature.asc Description: PGP signature
Re: [PATCH] kbuild: use -E instead of -c for __cc-option
On Fri, Jun 28, 2019 at 2:13 PM Masahiro Yamada wrote: > > Use -E instead of -c like scripts/Kconfig.include > This makes the compiler flag evaluation slightly faster. > > Signed-off-by: Masahiro Yamada > --- Applied to linux-kbuild. > scripts/Kbuild.include | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > index f641bb0aa63f..e4329b92d165 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -113,7 +113,7 @@ as-instr = $(call try-run,\ > # __cc-option > # Usage: MY_CFLAGS += $(call > __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586) > __cc-option = $(call try-run,\ > - $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) > + $(1) -Werror $(2) $(3) -E -x c /dev/null -o "$$TMP",$(3),$(4)) > > # Do not attempt to build with gcc plugins during cc-option tests. > # (And this uses delayed resolution so the flags will be up to date.) > -- > 2.17.1 > -- Best Regards Masahiro Yamada
Re: [PATCH v2] fixdep: check return value of printf() and putchar()
On Tue, Jun 25, 2019 at 3:54 PM Masahiro Yamada
wrote:
>
> When there is not enough space on your storage device, the build will
> fail with 'No space left on device' error message.
>
> The reason is obvious from the message, so you will free up some disk
> space, then you will resume the build.
>
> However, sometimes you may still see a mysterious error message:
>
> unterminated call to function 'wildcard': missing ')'.
>
> If you run out of the disk space, fixdep may end up with generating
> incomplete .*.cmd files.
>
> For example, if the disk shortage occurs while fixdep is running
> print_dep(), the .*.cmd might be truncated like this:
>
>$(wildcard include/config/
>
> When you run 'make' next time, this broken .*.cmd will be included,
> then GNU Make will terminate parsing since it is a wrong syntax.
>
> Once this happens, you need to run 'make clean' or delete the broken
> .*.cmd file manually.
>
> Even if you do not see any error message, the .*.cmd files after any
> error could be potentially incomplete, and unreliable. You may miss
> the re-compilation due to missing header dependency.
>
> If printf() cannot output the string for disk shortage or whatever
> reason, it returns a negative value, but currently fixdep does not
> check it at all. Consequently, fixdep *successfully* generates a
> broken .*.cmd file. Make never notices that since fixdep exits with 0,
> which means success.
>
> Given the intended usage of fixdep, it must respect the return value
> of not only malloc(), but also printf() and putchar().
>
> This seems a long-standing issue since the introduction of fixdep.
>
> In old days, Kbuild tried to provide an extra safety by letting fixdep
> output to a temporary file and renaming it after everything is done:
>
> scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
> rm -f $(depfile);\
> mv -f $(dot-target).tmp $(dot-target).cmd)
>
> It did not avoid the current issue; fixdep created a truncated tmp file
> reporting success, so the broken tmp would be renamed to a .*.cmd file.
>
> By propagating the error code to the build system, this problem should
> be solved because:
>
> [1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
> target"), Make will delete the target automatically on any failure
> in the recipe.
>
> [2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to
> .*.cmd files"), .*.cmd file is included only when the corresponding
> target already exists.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild.
> Changes in v2:
> - Add prror()
>
> scripts/basic/fixdep.c | 51 +-
> 1 file changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
> index facbd603adf6..4ac973f2dc8c 100644
> --- a/scripts/basic/fixdep.c
> +++ b/scripts/basic/fixdep.c
> @@ -99,6 +99,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -109,6 +110,36 @@ static void usage(void)
> exit(1);
> }
>
> +/*
> + * In the intended usage of this program, the stdout is redirected to .*.cmd
> + * The return value of printf() and putchar() must be checked to catch any
> + * error like "No space left on device".
> + */
> +static void xprintf(const char *format, ...)
> +{
> + va_list ap;
> + int ret;
> +
> + va_start(ap, format);
> + ret = vprintf(format, ap);
> + if (ret < 0) {
> + perror("fixdep");
> + exit(1);
> + }
> + va_end(ap);
> +}
> +
> +static void xputchar(int c)
> +{
> + int ret;
> +
> + ret = putchar(c);
> + if (ret == EOF) {
> + perror("fixdep");
> + exit(1);
> + }
> +}
> +
> /*
> * Print out a dependency path from a symbol name
> */
> @@ -116,7 +147,7 @@ static void print_dep(const char *m, int slen, const char
> *dir)
> {
> int c, prev_c = '/', i;
>
> - printf("$(wildcard %s/", dir);
> + xprintf("$(wildcard %s/", dir);
> for (i = 0; i < slen; i++) {
> c = m[i];
> if (c == '_')
> @@ -124,10 +155,10 @@ static void print_dep(const char *m, int slen, const
> char *dir)
> else
> c = tolower(c);
> if (c != '/' || prev_c != '/')
> - putchar(c);
> + xputchar(c);
> prev_c = c;
> }
> - printf(".h) \\\n");
> + xprintf(".h) \\\n");
> }
>
> struct item {
> @@ -324,13 +355,13 @@ static void parse_dep_file(char *m, const char *target)
> */
> if (!saw_any_target) {
> saw_any_target = 1;
> - printf("source_%s := %s\n\n",
> -
Re: linux-next: build failure after merge of the slave-dma tree
On 06-07-19, 13:43, Robin Gong wrote:
> Hi Stephen,
Please **do not** top post!
> That's caused by 'of_irq_count' NOT export to global symbol, and I'm
> curious why it has been
> here for so long since Zhangfei found it in 2015.
> https://patchwork.kernel.org/patch/7404681/
Yes this does not seem to be applied, perhaps Rob can explain why. But
this was not exported how did you test it?
> Hi Rob,
> Is there something I miss so that Zhangfei's patch not accepted finally?
Rob, the commit in question is [1] and uses of_irq_count. Should it use
that if not what is the alternate?
> On 04-07-19, 15:31 Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the slave-dma tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > ERROR: "of_irq_count" [drivers/dma/fsl-edma.ko] undefined!
> >
> > Caused by commit
> >
> > 7144afd025b2 ("dmaengine: fsl-edma: add i.mx7ulp edma2 version
> > support")
> >
> > I have reverted that commit for today.
> >
> > --
> > Cheers,
> > Stephen Rothwell
[1]:
http://git.infradead.org/users/vkoul/slave-dma.git/commitdiff/7144afd025b23b042c158582160d7d2b10a754b7?hp=a7c5c6f6bc295d6c158db4ef9d1ca6770032669d
--
~Vinod
Re: [PATCH 1/2] kbuild: fix missed rebuild of modules.builtin
On Mon, Jun 24, 2019 at 1:13 AM Masahiro Yamada wrote: > > Unlike modules.order, modules.builtin is not rebuilt every time. > Once modules.builtin is created, it will not be updated until > auto.conf or tristate.conf is changed. > > So, it misses to notice a change in Makefile, for example, renaming > of modules. > > Kbuild must always descend into directories for modules.builtin too. > > Signed-off-by: Masahiro Yamada > --- Both applied to linux-kbuild. > > Makefile | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/Makefile b/Makefile > index 9514dac2660a..19c33bc69bb1 100644 > --- a/Makefile > +++ b/Makefile > @@ -1289,12 +1289,16 @@ modules: $(vmlinux-dirs) $(if > $(KBUILD_BUILTIN),vmlinux) modules.builtin > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost > $(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh > > -modules.builtin: $(vmlinux-dirs:%=%/modules.builtin) > - $(Q)$(AWK) '!x[$$0]++' $^ > $(objtree)/modules.builtin > +modbuiltin-dirs := $(addprefix _modbuiltin_, $(vmlinux-dirs)) > > -%/modules.builtin: include/config/auto.conf include/config/tristate.conf > - $(Q)$(MAKE) $(modbuiltin)=$* > +modules.builtin: $(modbuiltin-dirs) > + $(Q)$(AWK) '!x[$$0]++' $(addsuffix /$@, $(vmlinux-dirs)) > $@ > > +PHONY += $(modbuiltin-dirs) > +# tristate.conf is not included from this Makefile. Add it as a prerequisite > +# here to make it self-healing in case somebody accidentally removes it. > +$(modbuiltin-dirs): include/config/tristate.conf > + $(Q)$(MAKE) $(modbuiltin)=$(patsubst _modbuiltin_%,%,$@) > > # Target to prepare building external modules > PHONY += modules_prepare > -- > 2.17.1 > -- Best Regards Masahiro Yamada
Re: [PATCH 1/3] kbuild: rename arg-check to cmd-check
On Sun, Jun 23, 2019 at 1:07 AM Masahiro Yamada wrote: > > I prefer 'cmd-check' for consistency. > > We have 'echo-cmd', 'cmd', 'cmd_and_fixdep', etc. in this file. > > Signed-off-by: Masahiro Yamada > --- Series, applied to linux-kbuild. > scripts/Kbuild.include | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > index f641bb0aa63f..4bec04c89750 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -213,12 +213,12 @@ objectify = $(foreach o,$(1),$(if $(filter > /%,$(o)),$(o),$(obj)/$(o))) > # See Documentation/kbuild/makefiles.txt for more info > > ifneq ($(KBUILD_NOCMDDEP),1) > -# Check if both arguments are the same including their order. Result is empty > +# Check if both commands are the same including their order. Result is empty > # string if equal. User may override this check using make KBUILD_NOCMDDEP=1 > -arg-check = $(filter-out $(subst $(space),$(space_escape),$(strip > $(cmd_$@))), \ > +cmd-check = $(filter-out $(subst $(space),$(space_escape),$(strip > $(cmd_$@))), \ > $(subst $(space),$(space_escape),$(strip > $(cmd_$1 > else > -arg-check = $(if $(strip $(cmd_$@)),,1) > +cmd-check = $(if $(strip $(cmd_$@)),,1) > endif > > # Replace >$< with >$$< to preserve $ when reloading the .cmd file > @@ -234,12 +234,12 @@ make-cmd = $(call escsq,$(subst > $(pound),$$(pound),$(subst $$,,$(cmd_$(1 > any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard > $^),$^) > > # Execute command if command has changed or prerequisite(s) are updated. > -if_changed = $(if $(strip $(any-prereq) $(arg-check)), > \ > +if_changed = $(if $(strip $(any-prereq) $(cmd-check)), > \ > $(cmd); \ > printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:) > > # Execute the command and also postprocess generated .d dependencies file. > -if_changed_dep = $(if $(strip $(any-prereq) > $(arg-check)),$(cmd_and_fixdep),@:) > +if_changed_dep = $(if $(strip $(any-prereq) > $(cmd-check)),$(cmd_and_fixdep),@:) > > cmd_and_fixdep = > \ > $(cmd); \ > @@ -249,7 +249,7 @@ cmd_and_fixdep = >\ > # Usage: $(call if_changed_rule,foo) > # Will check if $(cmd_foo) or any of the prerequisites changed, > # and if so will execute $(rule_foo). > -if_changed_rule = $(if $(strip $(any-prereq) $(arg-check)),$(rule_$(1)),@:) > +if_changed_rule = $(if $(strip $(any-prereq) $(cmd-check)),$(rule_$(1)),@:) > > ### > # why - tell why a target got built > @@ -275,7 +275,7 @@ why = >\ > $(if $(filter $@, $(PHONY)),- due to target is PHONY, > \ > $(if $(wildcard $@), > \ > $(if $(strip $(any-prereq)),- due to: $(any-prereq), > \ > -$(if $(arg-check), > \ > +$(if $(cmd-check), > \ > $(if $(cmd_$@),- due to command line change, > \ > $(if $(filter $@, $(targets)), > \ > - due to missing .cmd file, > \ > -- > 2.17.1 > -- Best Regards Masahiro Yamada
Re: INFO: rcu detected stall in ext4_write_checks
On Fri, Jul 05, 2019 at 11:16:31PM -0700, Paul E. McKenney wrote: > I suppose RCU could take the dueling-banjos approach and use increasingly > aggressive scheduler policies itself, up to and including SCHED_DEADLINE, > until it started getting decent forward progress. However, that > sounds like the something that just might have unintended consequences, > particularly if other kernel subsystems were to also play similar > games of dueling banjos. So long as the RCU threads are well-behaved, using SCHED_DEADLINE shouldn't have much of an impact on the system --- and the scheduling parameters that you can specify on SCHED_DEADLINE allows you to specify the worst-case impact on the system while also guaranteeing that the SCHED_DEADLINE tasks will urn in the first place. After all, that's the whole point of SCHED_DEADLINE. So I wonder if the right approach is during the the first userspace system call to shced_setattr to enable a (any) real-time priority scheduler (SCHED_DEADLINE, SCHED_FIFO or SCHED_RR) on a userspace thread, before that's allowed to proceed, the RCU kernel threads are promoted to be SCHED_DEADLINE with appropriately set deadline parameters. That way, a root user won't be able to shoot the system in the foot, and since the vast majority of the time, there shouldn't be any processes running with real-time priorities, we won't be changing the behavior of a normal server system. (I suspect there might be some audio applications that might try to set real-time priorities, but for desktop systems, it's probably more important that the system not tie its self into knots since the average desktop user isn't going to be well equipped to debug the problem.) > Alternatively, is it possible to provide stricter admission control? I think that's an orthogonal issue; better admission control would be nice, but it looks to me that it's going to be fundamentally an issue of tweaking hueristics, and a fool-proof solution that will protect against all malicious userspace applications (including syzkaller) is going to require solving the halting problem. So while it would be nice to improve the admission control, I don't think that's a going to be a general solution. - Ted
Re: [PATCH v5 00/12] S.A.R.A. a new stacked LSM
You are right. I just forgot to remove that paragraph from the cover letter. My bad. Thank you for noticing that :) Il giorno sab 6 lug 2019 alle ore 16:33 Jordan Glover ha scritto: > > On Saturday, July 6, 2019 10:54 AM, Salvatore Mesoraca > wrote: > > > S.A.R.A. is meant to be stacked but it needs cred blobs and the procattr > > interface, so I temporarily implemented those parts in a way that won't > > be acceptable for upstream, but it works for now. I know that there > > is some ongoing work to make cred blobs and procattr stackable, as soon > > as the new interfaces will be available I'll reimplement the involved > > parts. > > I thought all stacking pieces for minor LSM were merged in Linux 5.1. > Is there still something missing or is this comment out-fo-date? > > Jordan
[PATCH] security/commoncap: Use xattr security prefix len
Using the existing defined XATTR_SECURITY_PREFIX_LEN instead of
sizeof(XATTR_SECURITY_PREFIX) - 1. Pretty simple cleanup.
Signed-off-by: Carmeli Tamir
---
security/commoncap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index c0b9664ee49e..99d1fcae22fd 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -915,7 +915,7 @@ int cap_inode_setxattr(struct dentry *dentry, const char
*name,
/* Ignore non-security xattrs */
if (strncmp(name, XATTR_SECURITY_PREFIX,
- sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
+ XATTR_SECURITY_PREFIX_LEN) != 0)
return 0;
/*
@@ -947,7 +947,7 @@ int cap_inode_removexattr(struct dentry *dentry, const char
*name)
/* Ignore non-security xattrs */
if (strncmp(name, XATTR_SECURITY_PREFIX,
- sizeof(XATTR_SECURITY_PREFIX) - 1) != 0)
+ XATTR_SECURITY_PREFIX_LEN) != 0)
return 0;
if (strcmp(name, XATTR_NAME_CAPS) == 0) {
--
2.21.0
Regression in mdadm breaks assembling of array
(Off list, please keep me in CC, thx!) Hi there, TL;DR: https://github.com/neilbrown/mdadm/commit611d95290dd41d73bd8f9cc06f7ec293a40b819e regresses mdadm and does not let me assemble my main drive due to kernel error md: invalid array_size 125035870 > default size 125035776 caused by changed reservation size in mdadm, and thus reduced "Usable Size" being reduced too much (smaller than 0.5 * Array Size). Full write-up with logs etc here: https://forum.manjaro.org/t/mdadm-issues-live-cd-works-existing-install-breaks-fakeraid-imsm/93613 I chased through both 4.0 mdadm (which works, e.g., from a Live image), and the new 4.1 version (from Manjaro update), and the same disk in the same machine works with the older, and refuses to work with the newer mdadm. The kernel message suggests that the kernel refuses to assemble the array, and tracing the computation back through both versions (4.0 and GIT head 3c9b46cf9ae15a9be98fc47e2080bd9494496246 ) reveals that both versions end up using the default for reserved space, which is MPB_SECTOR_CNT + IMSM_RESERVED_SECTORS (the other difference between the versions is the size computed, but that is hopefully intentional due to 444909385fdaccf961308c4319d7029b82bf8bb1 ). I understand too little to propose a fix or know why the defaults were changed, but this is clearly a regression, and the disk works in the same machine in Windows, and with older Live images. More log output in the Manjaro forum thread, and I have some more log output with printf's sprinkled around if necessary. Happy to help fix this, please have a look :) Thanks, Stephan
Re: suspend broken in next-20190704 on Thinkpad X60
Hi! > > > > Suspend is broken in next-20190704 on Thinkpad X60. > > > > > > Broken in what way? Any details? > > > > > > > It very very probably worked ok in 20190701. > > > > > > Well, please try the linux-next branch from linux-pm.git > > > (git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git) > > > alone and see if that fails. > > > > So... let me try this one? > > > > commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch) > > treecb5339fcaae2166832f91f4ce9f40575cc6cb6e5 > > parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff) > > parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff) > > download > > linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz > > Merge branch 'pm-cpufreq-new' into > > linux-nexttestinglinux-nextbleeding-edge > > * pm-cpufreq-new: > > > > That one is broken, too. > > > > pavel@amd:~$ sudo pm-suspend > > > > Machine suspends, resumes, but I don't get my prompt back. > > I'm not sure what you mean here. I'm guessing that you don't get back > to the console from which you ran the pm-suspend command, but is X > restored, for example? Is there any way to get into the system in > that state? X is restored, and the rest of system works, but "pm-suspend" command never completes, so I don't get shell prompt back in that window. > Anyway, if 5.2-rc7 is OK, something in this branch causes the problem > to happen for you. > > I would try > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244 > > to narrow down the scope somewhat. next-20190701 is ok, next-20190704 is broken. Can we use that to narrow it down? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] Bluetooth: hci_ldisc: check for missing tty operations
Hello, Marcel, I totally agree, the same came to my mind some time after sending the patch. Let me send a v2 in a while with drivers checking for needed tty operations presence. Best regards, Vladis Dronov | Red Hat, Inc. | The Core Kernel | Senior Software Engineer - Original Message - > From: "Marcel Holtmann" > To: "Vladis Dronov" > Cc: "Johan Hedberg" , > linux-blueto...@vger.kernel.org, linux-kernel@vger.kernel.org, > syzbot+79337b501d6aa974d...@syzkaller.appspotmail.com, > sta...@vger.kernel.org, "Loic Poulain" > , "Ilya Faenson" > Sent: Saturday, July 6, 2019 12:35:39 PM > Subject: Re: [PATCH] Bluetooth: hci_ldisc: check for missing tty operations > > Hi Vladis, > > > Certain ttys lack operations (eg: pty_unix98_ops) which still can be > > called by certain hci uart proto (eg: mrvl, ath). Currently this leads > > to execution at address 0x0. Fix this by adding checks for missing tty > > operations. > > so I really prefer that we just fail setting the line discipline. These > drivers need to check that the underlying transport has all the operations > available they need. We can not just ignore them. > > Regards > > Marcel
Re: [PATCH v5 02/12] S.A.R.A.: create framework
Hi, On 7/6/19 3:54 AM, Salvatore Mesoraca wrote: > diff --git a/security/sara/Kconfig b/security/sara/Kconfig > new file mode 100644 > index 000..0456220 > --- /dev/null > +++ b/security/sara/Kconfig > @@ -0,0 +1,40 @@ > +menuconfig SECURITY_SARA > + bool "S.A.R.A." > + depends on SECURITY > + select SECURITYFS > + default n No need for "default n". Drop it, please. > + help > + This selects S.A.R.A. LSM which aims to collect heterogeneous > + security measures providing a common interface to manage them. > + This LSM will always be stacked with the selected primary LSM and > + other stacked LSMs. > + Further information can be found in > + Documentation/admin-guide/LSM/SARA.rst. > + > + If unsure, answer N. > + > +config SECURITY_SARA_DEFAULT_DISABLED > + bool "S.A.R.A. will be disabled at boot." > + depends on SECURITY_SARA > + default n > + help > + If you say Y here, S.A.R.A. will not be enabled at startup. You can > + override this option at boot time via "sara.enabled=[1|0]" kernel > + parameter or via user-space utilities. > + This option is useful for distro kernels. > + > + If unsure, answer N. > + > +config SECURITY_SARA_NO_RUNTIME_ENABLE > + bool "S.A.R.A. can be turn on only at boot time." can be turned on > + depends on SECURITY_SARA_DEFAULT_DISABLED > + default y > + help > + By enabling this option it won't be possible to turn on S.A.R.A. > + at runtime via user-space utilities. However it can still be > + turned on at boot time via the "sara.enabled=1" kernel parameter. > + This option is functionally equivalent to "sara.enabled=0" kernel > + parameter. This option is useful for distro kernels. > + > + If unsure, answer Y. > + -- ~Randy
Re: [PATCH v5 08/12] S.A.R.A.: trampoline emulation
On 7/6/19 3:54 AM, Salvatore Mesoraca wrote: > diff --git a/security/sara/Kconfig b/security/sara/Kconfig > index 54a96e0..458e0e8 100644 > --- a/security/sara/Kconfig > +++ b/security/sara/Kconfig > @@ -117,6 +117,24 @@ choice > Documentation/admin-guide/LSM/SARA.rst. > endchoice > > +config SECURITY_SARA_WXPROT_EMUTRAMP > + bool "Enable emulation for some types of trampolines" > + depends on SECURITY_SARA_WXPROT > + depends on ARCH_HAS_LSM_PAGEFAULT > + depends on X86 > + default y > + help > + Some programs and libraries need to execute special small code > + snippets from non-executable memory pages. > + Most notable examples are the GCC and libffi trampolines. > + This features make it possible to execute those trampolines even This feature makes it possible > + if they reside in non-executable memory pages. > + This features need to be enabled on a per-executable basis This feature needs to be > + via user-space utilities. > + See Documentation/admin-guide/LSM/SARA.rst. for further information. > + > + If unsure, answer y. > + > config SECURITY_SARA_WXPROT_DISABLED > bool "WX protection will be disabled at boot." > depends on SECURITY_SARA_WXPROT -- ~Randy
Re: suspend broken in next-20190704 on Thinkpad X60
Hi! > > commit 1e2a4c9019eb53f62790fadf86c14a54f4cf4888 (patch) > > treecb5339fcaae2166832f91f4ce9f40575cc6cb6e5 > > parent 3836c60c063581294c3a82f8cbccf3f702951358 (diff) > > parent 0a811974f3f79eea299af79c29595d8e1cb80a15 (diff) > > download > > linux-pm-1e2a4c9019eb53f62790fadf86c14a54f4cf4888.tar.gz > > Merge branch 'pm-cpufreq-new' into > > linux-nexttestinglinux-nextbleeding-edge > > * pm-cpufreq-new: > > > > That one is broken, too. > > > > pavel@amd:~$ sudo pm-suspend > > > > Machine suspends, resumes, but I don't get my prompt back. > > I'm not sure what you mean here. I'm guessing that you don't get back > to the console from which you ran the pm-suspend command, but is X > restored, for example? Is there any way to get into the system in > that state? > > Anyway, if 5.2-rc7 is OK, something in this branch causes the problem > to happen for you. > > I would try > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244 That one is good. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v5 06/12] S.A.R.A.: WX protection
On 7/6/19 3:54 AM, Salvatore Mesoraca wrote: > diff --git a/security/sara/Kconfig b/security/sara/Kconfig > index b98cf27..54a96e0 100644 > --- a/security/sara/Kconfig > +++ b/security/sara/Kconfig > @@ -60,3 +60,77 @@ config SECURITY_SARA_NO_RUNTIME_ENABLE > > If unsure, answer Y. > > +config SECURITY_SARA_WXPROT > + bool "WX Protection: W^X and W!->X protections" > + depends on SECURITY_SARA > + default y > + help > + WX Protection aims to improve user-space programs security by > applying: > + - W^X memory restriction > + - W!->X (once writable never executable) mprotect restriction > + - Executable MMAP prevention > + See Documentation/admin-guide/LSM/SARA.rst. for further information. .rst for further information. > + > + If unsure, answer Y. > + > +choice > + prompt "Default action for W^X and W!->X protections" > + depends on SECURITY_SARA > + depends on SECURITY_SARA_WXPROT > + default SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_COMPLAIN_VERBOSE > + > +help Use tab instead of spaces for indentation above. > + Choose the default behaviour of WX Protection when no config > + rule matches or no rule is loaded. > + For further information on available flags and their meaning > + see Documentation/admin-guide/LSM/SARA.rst. > + > + config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_COMPLAIN_VERBOSE > + bool "Protections enabled but not enforced." > + help > + All features enabled except "Executable MMAP prevention", > + verbose reporting, but no actual enforce: it just complains. > + Its numeric value is 0x3f, for more information see > + Documentation/admin-guide/LSM/SARA.rst. > + > +config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_ENFORCE_VERBOSE > + bool "Full protection, verbose." > + help > + All features enabled except "Executable MMAP prevention". > + The enabled features will be enforced with verbose reporting. > + Its numeric value is 0x2f, for more information see > + Documentation/admin-guide/LSM/SARA.rst. > + > +config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_ENFORCE > + bool "Full protection, quiet." > + help > + All features enabled except "Executable MMAP prevention". > + The enabled features will be enforced quietly. > + Its numeric value is 0xf, for more information see > + Documentation/admin-guide/LSM/SARA.rst. > + > + config SECURITY_SARA_WXPROT_DEFAULT_FLAGS_NONE > + bool "No protection at all." > + help > + All features disabled. > + Its numeric value is 0, for more information see > + Documentation/admin-guide/LSM/SARA.rst. > +endchoice > + > +config SECURITY_SARA_WXPROT_DISABLED > + bool "WX protection will be disabled at boot." > + depends on SECURITY_SARA_WXPROT > + default n Omit "default n" please. > + help > + If you say Y here WX protection won't be enabled at startup. You can > + override this option via user-space utilities or at boot time via > + "sara.wxprot_enabled=[0|1]" kernel parameter. > + > + If unsure, answer N. > + > +config SECURITY_SARA_WXPROT_DEFAULT_FLAGS > + hex > + default "0x3f" if > SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_COMPLAIN_VERBOSE > + default "0x2f" if SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_ENFORCE_VERBOSE > + default "0xf" if SECURITY_SARA_WXPROT_DEFAULT_FLAGS_ALL_ENFORCE > + default "0" if SECURITY_SARA_WXPROT_DEFAULT_FLAGS_NONE -- ~Randy
Re: linux-next: Tree for Jul 4
On Sat, Jul 06, 2019 at 08:17:29PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Sat, 6 Jul 2019 11:46:47 +0200 Greg Kroah-Hartman
> wrote:
> >
> > On Sat, Jul 06, 2019 at 07:44:12PM +1000, Stephen Rothwell wrote:
> > >
> > > On Sat, 6 Jul 2019 10:34:33 +0200 Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Thu, Jul 04, 2019 at 10:24:50PM +1000, Stephen Rothwell wrote:
> > > > >
> > > > > This release produces a whole lot (over 200) of this message in my
> > > > > qemu
> > > > > boot tests:
> > > > >
> > > > > [1.698497] debugfs: File 'sched' already present!
> > > > >
> > > > > Introduced by commit
> > > > >
> > > > > 43e23b6c0b01 ("debugfs: log errors when something goes wrong")
> > > > >
> > > > > from the driver-core tree. I assume that the error(?) was already
> > > > > happening, but it is now being reported.
> > > >
> > > > What are you passing to qemu to get this? I just tried it myself and
> > > > see no error reports at all. Have a .config I can use to try to
> > > > reproduce this?
> > >
> > > It is a powerpc pseries_le_defconfig kernel and I run qemu like this:
> > >
> > > qemu-system-ppc64 -M pseries -m 2G -vga none -nographic -kernel vmlinux
> > > -initrd rootfs.cpio.gz
> >
> > Hm, I think my rootfs initrd might be quite simple compared to yours (it
> > drops me into a busybox shell). Any pointers to where you created yours
> > from?
>
> Michael Ellerman gave it to me. It is very simple. Its /init is just
>
> $ cat init
> #!/bin/sh
> # devtmpfs does not get automounted for initramfs
> /bin/mount -t devtmpfs devtmpfs /dev
> exec 0 exec 1>/dev/console
> exec 2>/dev/console
> exec /sbin/init $*
>
> and /sbin/init is a link to /bin/busybox
>
> It is all run by an expect script that just waits for the login:
> prompt, logs in a root and runs "halt".
>
> All the debugfs messages appear before the kernel finished booting.
Ah, found the bug. Turns out I caused it in the blk queue debugfs code
a short while ago. I'll post a patch for this in a few minutes...
thanks,
greg k-h
[PATCH] debugfs: make error message a bit more verbose
When a file/directory is already present in debugfs, and it is attempted
to be created again, be more specific about what file/directory is being
created and where it is trying to be created to give a bit more help to
developers to figure out the problem.
Cc: Stephen Rothwell
Cc: Rafael J. Wysocki
Cc: Mark Brown
Cc: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
fs/debugfs/inode.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 7f43c8acfcbf..5836312269e0 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -311,8 +311,13 @@ static struct dentry *start_creating(const char *name,
struct dentry *parent)
inode_lock(d_inode(parent));
dentry = lookup_one_len(name, parent, strlen(name));
if (!IS_ERR(dentry) && d_really_is_positive(dentry)) {
+ if (d_is_dir(dentry))
+ pr_err("Directory '%s' with parent '%s' already
present!\n",
+ name, parent->d_name.name);
+ else
+ pr_err("File '%s' in directory '%s' already present!\n",
+ name, parent->d_name.name);
dput(dentry);
- pr_err("File '%s' already present!\n", name);
dentry = ERR_PTR(-EEXIST);
}
--
2.22.0
Re: objtool warnings in prerelease clang-9
On Tue, Jul 02, 2019 at 11:58:27PM +0200, Thomas Gleixner wrote: > platform-quirks.o: > > if (x86_platform.set_legacy_features) > 74: 4c 8b 1d 00 00 00 00mov0x0(%rip),%r11# 7b > > 7b: 4d 85 dbtest %r11,%r11 > 7e: 0f 85 00 00 00 00 jne84 > > x86_platform.set_legacy_features(); > } > 84: c3 retq > > That jne jumps to __x86_indirect_thunk_r11, aka. ratpoutine. > > No idea why objtool thinks that the instruction at 0x84 is not > reachable. Josh? That's a conditional tail call, which is something GCC never does. Objtool doesn't understand that, so we'll need to fix it. -- Josh
Re: [PATCH] debugfs: make error message a bit more verbose
On Sat, Jul 06, 2019 at 05:42:56PM +0200, Greg Kroah-Hartman wrote: > When a file/directory is already present in debugfs, and it is attempted > to be created again, be more specific about what file/directory is being > created and where it is trying to be created to give a bit more help to > developers to figure out the problem. Reviewed-by: Mark Brown signature.asc Description: PGP signature
Hi, This is Clara
Are you there ?. Can I have a word with you privately?
Aw: Re: Re: [PATCH v2 3/7] rtc: mt6397: improvements of rtc driver
> Gesendet: Freitag, 05. Juli 2019 um 23:24 Uhr > Von: "Alexandre Belloni" > Let's say the RTC has been used to start your platform, then the irq > handler will be called as soon as the irq is requested, leading to a > null pointer dereference. i cannot test this with my platform, but i have changed it in my repo https://github.com/frank-w/BPI-R2-4.14/commits/5.2-poweroff-mainline > Yes and IIRC, I did comment that the rtc change also had to be separated > from 1/7. also this is put in separate commit, can you take a look before i post v3? > Also, I really doubt this new compatible is necessary at all as you > could simply directly use mediatek,mt6397-rtc. imho this can confuse because the wrong chip-name is used in dts regards Frank
[GIT PULL] MIPS fixes
Hi Linus, Apologies that these are arriving so late in the game, but here are a few MIPS fixes heading your way from a beachside cafe. It's all pretty small, nothing too scary or invasive. Please pull. Thanks, Paul The following changes since commit 9e0babf2c06c73cda2c0cd37a1653d823adb40ec: Linux 5.2-rc5 (2019-06-16 08:49:45 -1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_fixes_5.2_2 for you to fetch changes up to f2ff671f894151a611eae246a1f25b61d6c0354b: MAINTAINERS: Correct path to moved files (2019-06-24 14:45:41 -0700) A few more MIPS fixes: - Fix a silly typo in virt_addr_valid which led to completely bogus behavior (that happened to stop tripping up hardened usercopy despite being broken). - Fix UART parity setup on AR933x systems. - A build fix for non-Linux build machines. - Have the 'all' make target build DTBs, primarily to fit in with the behavior of scripts/package/builddeb. - Handle an execution hazard in TLB exceptions that use KScratch registers, which could inadvertently clobber the $1 register on some generally higher-end out-of-order CPUs. - A MAINTAINERS update to fix the path to the NAND driver for Ingenic systems. Cedric Hombourger (1): MIPS: have "plain" make calls build dtbs for selected platforms Dmitry Korotin (1): MIPS: Add missing EHB in mtc0 -> mfc0 sequence. Hauke Mehrtens (1): MIPS: Fix bounds check virt_addr_valid Kevin Darbyshire-Bryant (1): MIPS: fix build on non-linux hosts Paul Cercueil (1): MAINTAINERS: Correct path to moved files Stefan Hellermann (1): MIPS: ath79: fix ar933x uart parity mode MAINTAINERS| 2 +- arch/mips/Makefile | 3 ++- arch/mips/boot/compressed/Makefile | 2 ++ arch/mips/boot/compressed/calc_vmlinuz_load_addr.c | 2 +- arch/mips/include/asm/mach-ath79/ar933x_uart.h | 4 +-- arch/mips/mm/mmap.c| 2 +- arch/mips/mm/tlbex.c | 29 +++--- 7 files changed, 29 insertions(+), 15 deletions(-) signature.asc Description: PGP signature
[PATCH 2/3] mfd: ab8500: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Linus Walleij
Cc: Lee Jones
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/mfd/ab8500-debugfs.c | 324 +++
1 file changed, 98 insertions(+), 226 deletions(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index d24c6ecccb88..567a34b073dd 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -2644,12 +2644,10 @@ static const struct file_operations ab8500_hwreg_fops =
{
.owner = THIS_MODULE,
};
-static struct dentry *ab8500_dir;
-static struct dentry *ab8500_gpadc_dir;
-
static int ab8500_debug_probe(struct platform_device *plf)
{
- struct dentry *file;
+ struct dentry *ab8500_dir;
+ struct dentry *ab8500_gpadc_dir;
struct ab8500 *ab8500;
struct resource *res;
@@ -2694,47 +2692,22 @@ static int ab8500_debug_probe(struct platform_device
*plf)
}
ab8500_dir = debugfs_create_dir(AB8500_NAME_STRING, NULL);
- if (!ab8500_dir)
- goto err;
ab8500_gpadc_dir = debugfs_create_dir(AB8500_ADC_NAME_STRING,
ab8500_dir);
- if (!ab8500_gpadc_dir)
- goto err;
-
- file = debugfs_create_file("all-bank-registers", S_IRUGO, ab8500_dir,
- &plf->dev, &ab8500_bank_registers_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("all-banks", S_IRUGO, ab8500_dir,
- &plf->dev, &ab8500_all_banks_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("register-bank",
- (S_IRUGO | S_IWUSR | S_IWGRP),
- ab8500_dir, &plf->dev, &ab8500_bank_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("register-address",
- (S_IRUGO | S_IWUSR | S_IWGRP),
- ab8500_dir, &plf->dev, &ab8500_address_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("register-value",
- (S_IRUGO | S_IWUSR | S_IWGRP),
- ab8500_dir, &plf->dev, &ab8500_val_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("irq-subscribe",
- (S_IRUGO | S_IWUSR | S_IWGRP), ab8500_dir,
- &plf->dev, &ab8500_subscribe_fops);
- if (!file)
- goto err;
+
+ debugfs_create_file("all-bank-registers", S_IRUGO, ab8500_dir,
+ &plf->dev, &ab8500_bank_registers_fops);
+ debugfs_create_file("all-banks", S_IRUGO, ab8500_dir,
+ &plf->dev, &ab8500_all_banks_fops);
+ debugfs_create_file("register-bank", (S_IRUGO | S_IWUSR | S_IWGRP),
+ ab8500_dir, &plf->dev, &ab8500_bank_fops);
+ debugfs_create_file("register-address", (S_IRUGO | S_IWUSR | S_IWGRP),
+ ab8500_dir, &plf->dev, &ab8500_address_fops);
+ debugfs_create_file("register-value", (S_IRUGO | S_IWUSR | S_IWGRP),
+ ab8500_dir, &plf->dev, &ab8500_val_fops);
+ debugfs_create_file("irq-subscribe", (S_IRUGO | S_IWUSR | S_IWGRP),
+ ab8500_dir, &plf->dev, &ab8500_subscribe_fops);
if (is_ab8500(ab8500)) {
debug_ranges = ab8500_debug_ranges;
@@ -2750,194 +2723,93 @@ static int ab8500_debug_probe(struct platform_device
*plf)
num_interrupt_lines = AB8540_NR_IRQS;
}
- file = debugfs_create_file("interrupts", (S_IRUGO), ab8500_dir,
- &plf->dev, &ab8500_interrupts_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("irq-unsubscribe",
- (S_IRUGO | S_IWUSR | S_IWGRP), ab8500_dir,
- &plf->dev, &ab8500_unsubscribe_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("hwreg", (S_IRUGO | S_IWUSR | S_IWGRP),
- ab8500_dir, &plf->dev, &ab8500_hwreg_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("all-modem-registers",
- (S_IRUGO | S_IWUSR | S_IWGRP),
- ab8500_dir, &plf->dev, &ab8500_modem_fops);
- if (!file)
- goto err;
-
- file = debugfs_create_file("bat_ctrl", (S_IRUGO | S_IWUSR | S_IWGRP),
- ab8500_gpadc_dir, &plf->dev,
- &ab8500_gpadc_bat
[PATCH 1/3] mfd: ab3100: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Linus Walleij
Cc: Lee Jones
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/mfd/ab3100-core.c | 45 ++-
drivers/mfd/ab3100-otp.c | 21 ++
2 files changed, 13 insertions(+), 53 deletions(-)
diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index e350ab64238e..9f3dbc31d3e9 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -575,58 +575,27 @@ static const struct file_operations
ab3100_get_set_reg_fops = {
.llseek = noop_llseek,
};
-static struct dentry *ab3100_dir;
-static struct dentry *ab3100_reg_file;
static struct ab3100_get_set_reg_priv ab3100_get_priv;
-static struct dentry *ab3100_get_reg_file;
static struct ab3100_get_set_reg_priv ab3100_set_priv;
-static struct dentry *ab3100_set_reg_file;
static void ab3100_setup_debugfs(struct ab3100 *ab3100)
{
- int err;
+ struct dentry *ab3100_dir;
ab3100_dir = debugfs_create_dir("ab3100", NULL);
- if (!ab3100_dir)
- goto exit_no_debugfs;
- ab3100_reg_file = debugfs_create_file("registers",
- S_IRUGO, ab3100_dir, ab3100,
- &ab3100_registers_fops);
- if (!ab3100_reg_file) {
- err = -ENOMEM;
- goto exit_destroy_dir;
- }
+ debugfs_create_file("registers", S_IRUGO, ab3100_dir, ab3100,
+ &ab3100_registers_fops);
ab3100_get_priv.ab3100 = ab3100;
ab3100_get_priv.mode = false;
- ab3100_get_reg_file = debugfs_create_file("get_reg",
- S_IWUSR, ab3100_dir, &ab3100_get_priv,
- &ab3100_get_set_reg_fops);
- if (!ab3100_get_reg_file) {
- err = -ENOMEM;
- goto exit_destroy_reg;
- }
+ debugfs_create_file("get_reg", S_IWUSR, ab3100_dir, &ab3100_get_priv,
+ &ab3100_get_set_reg_fops);
ab3100_set_priv.ab3100 = ab3100;
ab3100_set_priv.mode = true;
- ab3100_set_reg_file = debugfs_create_file("set_reg",
- S_IWUSR, ab3100_dir, &ab3100_set_priv,
- &ab3100_get_set_reg_fops);
- if (!ab3100_set_reg_file) {
- err = -ENOMEM;
- goto exit_destroy_get_reg;
- }
- return;
-
- exit_destroy_get_reg:
- debugfs_remove(ab3100_get_reg_file);
- exit_destroy_reg:
- debugfs_remove(ab3100_reg_file);
- exit_destroy_dir:
- debugfs_remove(ab3100_dir);
- exit_no_debugfs:
- return;
+ debugfs_create_file("set_reg", S_IWUSR, ab3100_dir, &ab3100_set_priv,
+ &ab3100_get_set_reg_fops);
}
#else
static inline void ab3100_setup_debugfs(struct ab3100 *ab3100)
diff --git a/drivers/mfd/ab3100-otp.c b/drivers/mfd/ab3100-otp.c
index b3f8d359f409..c4751fb9bc22 100644
--- a/drivers/mfd/ab3100-otp.c
+++ b/drivers/mfd/ab3100-otp.c
@@ -122,17 +122,11 @@ static const struct file_operations ab3100_otp_operations
= {
.release= single_release,
};
-static int __init ab3100_otp_init_debugfs(struct device *dev,
- struct ab3100_otp *otp)
+static void __init ab3100_otp_init_debugfs(struct device *dev,
+ struct ab3100_otp *otp)
{
otp->debugfs = debugfs_create_file("ab3100_otp", S_IFREG | S_IRUGO,
- NULL, otp,
- &ab3100_otp_operations);
- if (!otp->debugfs) {
- dev_err(dev, "AB3100 debugfs OTP file registration failed!\n");
- return -ENOENT;
- }
- return 0;
+ NULL, otp, &ab3100_otp_operations);
}
static void __exit ab3100_otp_exit_debugfs(struct ab3100_otp *otp)
@@ -141,10 +135,9 @@ static void __exit ab3100_otp_exit_debugfs(struct
ab3100_otp *otp)
}
#else
/* Compile this out if debugfs not selected */
-static inline int __init ab3100_otp_init_debugfs(struct device *dev,
-struct ab3100_otp *otp)
+static inline void __init ab3100_otp_init_debugfs(struct device *dev,
+ struct ab3100_otp *otp)
{
- return 0;
}
static inline void __exit ab3100_otp_exit_debugfs(struct ab3100_otp *otp)
@@ -211,9 +204,7 @@ static int __init ab3100_otp_probe(struct platform_device
*pdev)
}
/* debugfs entries */
- err = ab3100_otp_init_debugfs(&pdev->dev, otp);
- if (err)
- goto err;
+ ab3100_otp_init_debugfs(&pdev->dev, otp);
return 0;
--
2.22.0
[PATCH 3/3] mfd: aat2870: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Lee Jones
Signed-off-by: Greg Kroah-Hartman
---
drivers/mfd/aat2870-core.c | 13 ++---
include/linux/mfd/aat2870.h | 1 -
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c
index 9d3d90d386c2..51f4c10d2f36 100644
--- a/drivers/mfd/aat2870-core.c
+++ b/drivers/mfd/aat2870-core.c
@@ -334,18 +334,9 @@ static const struct file_operations aat2870_reg_fops = {
static void aat2870_init_debugfs(struct aat2870_data *aat2870)
{
aat2870->dentry_root = debugfs_create_dir("aat2870", NULL);
- if (!aat2870->dentry_root) {
- dev_warn(aat2870->dev,
-"Failed to create debugfs root directory\n");
- return;
- }
- aat2870->dentry_reg = debugfs_create_file("regs", 0644,
- aat2870->dentry_root,
- aat2870, &aat2870_reg_fops);
- if (!aat2870->dentry_reg)
- dev_warn(aat2870->dev,
-"Failed to create debugfs register file\n");
+ debugfs_create_file("regs", 0644, aat2870->dentry_root, aat2870,
+ &aat2870_reg_fops);
}
#else
diff --git a/include/linux/mfd/aat2870.h b/include/linux/mfd/aat2870.h
index f7316c29bdec..d9542246bd44 100644
--- a/include/linux/mfd/aat2870.h
+++ b/include/linux/mfd/aat2870.h
@@ -149,7 +149,6 @@ struct aat2870_data {
/* for debugfs */
struct dentry *dentry_root;
- struct dentry *dentry_reg;
};
struct aat2870_subdev_info {
--
2.22.0
Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform_driver
Hi Greg, On Sat, Jul 6, 2019 at 1:32 AM Greg Kroah-Hartman wrote: > > On Thu, Jul 04, 2019 at 02:17:22PM -0700, Dmitry Torokhov wrote: > > Hi Greg, > > > > On Thu, Jul 4, 2019 at 5:15 AM Greg Kroah-Hartman > > wrote: > > > > > > Platform drivers like to add sysfs groups to their device, but right now > > > they have to do it "by hand". The driver core should handle this for > > > them, but there is no way to get to the bus-default attribute groups as > > > all platform devices are "special and unique" one-off drivers/devices. > > > > > > To combat this, add a dev_groups pointer to platform_driver which allows > > > a platform driver to set up a list of default attributes that will be > > > properly created and removed by the platform driver core when a probe() > > > function is successful and removed right before the device is unbound. > > > > Why is this limited to platform bus? Drivers for other buses also > > often want to augment list of their attributes during probe(). I'd > > move it to generic probe handling. > > This is not limited to the platform at all, the driver core supports > this for any bus type today, but it's then up to the bus-specific code > to pass that on to the driver core. That's usually set for the > bus-specific attributes that they want exposed for all devices of that > bus type (see the bus_groups, dev_groups, and drv_groups pointers in > struct bus_type). > > For the platform devices, the problem is that this is something that the > individual drivers want after they bind to the device. And as all > platform devices are "different" they can't be a "common" set of > attributes, so they need to be created after the device is bound to the > driver. I believe that your assertion that only platform devices want to install custom attributes is incorrect. Drivers for devices attached to serio, i2c, USB, spi, etc, etc, all have additional attributes: dtor@dtor-ws:~/kernel/work (master *)$ grep -l '\(i2c\|usb\|spi\)' `git grep -l '\(device_add_group\|sysfs_create_group\)' -- drivers` | wc -l 170 I am pretty sure some of this count is false positives, but majority is actually proper hits. ... > > > > We already emit KOBJ_BIND when we finish binding device to a driver, > > regardless of the bus. I know we still need to teach systemd to handle > > it properly, but I think it is better than sprinkling KOBJ_CHANGE > > around. > > But the object's attributes did just change, which is what KOBJ_CHANGE > tells userspace, so this should be the correct thing to say to > userspace. > > And yes, ideally KOBJ_BIND would be handled, and it will be sent once > the device's probe function succeeds, but we have to deal with old > userspaces as well, right? Not for the new functionality, I do not think so. Newer kernels should be compatible with older userspace as it not breaking it, but new functionality is not guaranteed to be available with older userspace. Thanks. -- Dmitry
Re: [PATCH v5 01/12] S.A.R.A.: add documentation
Hi, Just a few typo fixes (inline). On 7/6/19 3:54 AM, Salvatore Mesoraca wrote: > Adding documentation for S.A.R.A. LSM. > > Signed-off-by: Salvatore Mesoraca > --- > Documentation/admin-guide/LSM/SARA.rst | 177 > > Documentation/admin-guide/LSM/index.rst | 1 + > Documentation/admin-guide/kernel-parameters.txt | 24 > 3 files changed, 202 insertions(+) > create mode 100644 Documentation/admin-guide/LSM/SARA.rst > > diff --git a/Documentation/admin-guide/LSM/SARA.rst > b/Documentation/admin-guide/LSM/SARA.rst > new file mode 100644 > index 000..fdde04c > --- /dev/null > +++ b/Documentation/admin-guide/LSM/SARA.rst > @@ -0,0 +1,177 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > + > +S.A.R.A. > + > + > +S.A.R.A. (S.A.R.A. is Another Recursive Acronym) is a stacked Linux Security > +Module that aims to collect heterogeneous security measures, providing a > common > +interface to manage them. > +As of today it consists of one submodule: > + > +- WX Protection > + > + > +The kernel-space part is complemented by its user-space counterpart: > `saractl` > +[2]_. > +A test suite for WX Protection, called `sara-test` [4]_, is also available. > +More information about where to find these tools and the full S.A.R.A. > +documentation are in the `External Links and Documentation`_ section. > + > +--- > + > +S.A.R.A.'s Submodules > += > + > +WX Protection > +- > +WX Protection aims to improve user-space programs security by applying: > + > +- `W^X enforcement`_ > +- `W!->X (once writable never executable) mprotect restriction`_ > +- `Executable MMAP prevention`_ > + > +All of the above features can be enabled or disabled both system wide > +or on a per executable basis through the use of configuration files managed > by > +`saractl` [2]_. > + > +It is important to note that some programs may have issues working with > +WX Protection. In particular: > + > +- **W^X enforcement** will cause problems to any programs that needs > + memory pages mapped both as writable and executable at the same time e.g. > + programs with executable stack markings in the *PT_GNU_STACK* segment. > +- **W!->X mprotect restriction** will cause problems to any program that > + needs to generate executable code at run time or to modify executable > + pages e.g. programs with a *JIT* compiler built-in or linked against a > + *non-PIC* library. > +- **Executable MMAP prevention** can work only with programs that have at > least > + partial *RELRO* support. It's disabled automatically for programs that > + lack this feature. It will cause problems to any program that uses *dlopen* > + or tries to do an executable mmap. Unfortunately this feature is the one > + that could create most problems and should be enabled only after careful > + evaluation. > + > +To extend the scope of the above features, despite the issues that they may > +cause, they are complemented by **/proc/PID/attr/sara/wxprot** interface > +and **trampoline emulation**. > + > +At the moment, WX Protection (unless specified otherwise) should work on > +any architecture supporting the NX bit, including, but not limited to: > +`x86_64`, `x86_32` (with PAE), `ARM` and `ARM64`. > + > +Parts of WX Protection are inspired by some of the features available in PaX. > + > +For further information about configuration file format and user-space > +utilities please take a look at the full documentation [1]_. > + > +W^X enforcement > +^^^ > +W^X means that a program can't have a page of memory that is marked, at the > +same time, writable and executable. This also allow to detect many bad allows > +behaviours that make life much more easy for attackers. Programs running with > +this feature enabled will be more difficult to exploit in the case they are > +affected by some vulnerabilities, because the attacker will be forced > +to make more steps in order to exploit them. > +This feature also blocks accesses to /proc/*/mem files that would allow to > +write the current process read-only memory, bypassing any protection. > + > +W!->X (once writable never executable) mprotect restriction > +^^^ > +"Once writable never executable" means that any page that could have been > +marked as writable in the past won't ever be allowed to be marked (e.g. via > +an mprotect syscall) as executable. > +This goes on the same track as W^X, but is much stricter and prevents > +the runtime creation of new executable code in memory. > +Obviously, this feature does not prevent a program from creating a new file > and > +*mmapping* it as executable, however, it will be way more difficult for > +attackers to exploit vulnerabilities if this feature is enabled. > + > +Executable MMAP prevention > +^
Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform_driver
On Sat, Jul 06, 2019 at 10:04:39AM -0700, Dmitry Torokhov wrote: > Hi Greg, > > On Sat, Jul 6, 2019 at 1:32 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jul 04, 2019 at 02:17:22PM -0700, Dmitry Torokhov wrote: > > > Hi Greg, > > > > > > On Thu, Jul 4, 2019 at 5:15 AM Greg Kroah-Hartman > > > wrote: > > > > > > > > Platform drivers like to add sysfs groups to their device, but right now > > > > they have to do it "by hand". The driver core should handle this for > > > > them, but there is no way to get to the bus-default attribute groups as > > > > all platform devices are "special and unique" one-off drivers/devices. > > > > > > > > To combat this, add a dev_groups pointer to platform_driver which allows > > > > a platform driver to set up a list of default attributes that will be > > > > properly created and removed by the platform driver core when a probe() > > > > function is successful and removed right before the device is unbound. > > > > > > Why is this limited to platform bus? Drivers for other buses also > > > often want to augment list of their attributes during probe(). I'd > > > move it to generic probe handling. > > > > This is not limited to the platform at all, the driver core supports > > this for any bus type today, but it's then up to the bus-specific code > > to pass that on to the driver core. That's usually set for the > > bus-specific attributes that they want exposed for all devices of that > > bus type (see the bus_groups, dev_groups, and drv_groups pointers in > > struct bus_type). > > > > For the platform devices, the problem is that this is something that the > > individual drivers want after they bind to the device. And as all > > platform devices are "different" they can't be a "common" set of > > attributes, so they need to be created after the device is bound to the > > driver. > > I believe that your assertion that only platform devices want to > install custom attributes is incorrect. Sorry, I didn't mean to imply that only platform drivers want to do this, as you say, many other drivers do as well. > Drivers for devices attached > to serio, i2c, USB, spi, etc, etc, all have additional attributes: > > dtor@dtor-ws:~/kernel/work (master *)$ grep -l '\(i2c\|usb\|spi\)' > `git grep -l '\(device_add_group\|sysfs_create_group\)' -- drivers` | > wc -l > 170 > > I am pretty sure some of this count is false positives, but majority > is actually proper hits. Yeah, I know, we need to add this type of functionality to those busses as well. I don't see a way of doing it other than this bus-by-bus conversion, do you? > > > We already emit KOBJ_BIND when we finish binding device to a driver, > > > regardless of the bus. I know we still need to teach systemd to handle > > > it properly, but I think it is better than sprinkling KOBJ_CHANGE > > > around. > > > > But the object's attributes did just change, which is what KOBJ_CHANGE > > tells userspace, so this should be the correct thing to say to > > userspace. > > > > And yes, ideally KOBJ_BIND would be handled, and it will be sent once > > the device's probe function succeeds, but we have to deal with old > > userspaces as well, right? > > Not for the new functionality, I do not think so. Newer kernels should > be compatible with older userspace as it not breaking it, but new > functionality is not guaranteed to be available with older userspace. I agree, but again, this is a kobject change (adding attributes), so I think the event type I picked here is the correct one. thanks, greg k-h
Re: [PATCH] perf: assign proper ff->ph in perf_event__synthesize_features()
Em Wed, Jun 19, 2019 at 06:04:53PM -0700, Song Liu escreveu:
> bpf/btf write_* functions need ff->ph->env.
>
> With this missing, pipe-mode (perf record -o -) would crash like:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> This patch assign proper ph value to ff.
Thanks, applied.
- Arnaldo
> Cc: sta...@vger.kernel.org #v5.1+
> Fixes: 606f972b1361 ("perf bpf: Save bpf_prog_info information as headers to
> perf.data")
> Reported-by: David Carrillo Cisneros
> Signed-off-by: Song Liu
> ---
> tools/perf/util/header.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 06ddb6618ef3..5f1aa0284e1b 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -3684,6 +3684,7 @@ int perf_event__synthesize_features(struct perf_tool
> *tool,
> return -ENOMEM;
>
> ff.size = sz - sz_hdr;
> + ff.ph = &session->header;
>
> for_each_set_bit(feat, header->adds_features, HEADER_FEAT_BITS) {
> if (!feat_ops[feat].synthesize) {
> --
> 2.17.1
