[PATCH] pwm_lpss: Add support for PCI devices
From: Alan Cox
Not all systems enumerate the PWM devices via ACPI. They can also be exposed
via the PCI interface.
Signed-off-by: Alan Cox
Signed-off-by: Chew, Chiau Ee
---
drivers/pwm/pwm-lpss.c | 160 ++-
1 files changed, 129 insertions(+), 31 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 449e372..6f79bf8 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -6,6 +6,7 @@
* Author: Chew Kean Ho
* Author: Chang Rebecca Swee Fun
* Author: Chew Chiau Ee
+ * Author: Alan Cox
*
* 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
@@ -19,6 +20,9 @@
#include
#include
#include
+#include
+
+static int pci_drv, plat_drv; /* So we know which drivers registered */
#define PWM0x
#define PWM_ENABLE BIT(31)
@@ -34,6 +38,15 @@ struct pwm_lpss_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clk;
+ unsigned long clk_rate;
+};
+
+struct pwm_lpss_boardinfo {
+ unsigned long clk_rate;
+};
+
+static const struct pwm_lpss_boardinfo byt_info = {
+ 2500
};
static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
@@ -55,7 +68,7 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct
pwm_device *pwm,
/* The equation is: base_unit = ((freq / c) * 65536) + correction */
base_unit = freq * 65536;
- c = clk_get_rate(lpwm->clk);
+ c = lpwm->clk_rate;
if (!c)
return -EINVAL;
@@ -113,52 +126,47 @@ static const struct pwm_ops pwm_lpss_ops = {
.owner = THIS_MODULE,
};
-static const struct acpi_device_id pwm_lpss_acpi_match[] = {
- { "80860F09", 0 },
- { },
-};
-MODULE_DEVICE_TABLE(acpi, pwm_lpss_acpi_match);
-
-static int pwm_lpss_probe(struct platform_device *pdev)
+static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
+ struct resource *r, struct pwm_lpss_boardinfo *info)
{
struct pwm_lpss_chip *lpwm;
- struct resource *r;
int ret;
- lpwm = devm_kzalloc(>dev, sizeof(*lpwm), GFP_KERNEL);
+ lpwm = devm_kzalloc(dev, sizeof(*lpwm), GFP_KERNEL);
if (!lpwm)
- return -ENOMEM;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ return ERR_PTR(-ENOMEM);
- lpwm->regs = devm_ioremap_resource(>dev, r);
+ lpwm->regs = devm_ioremap_resource(dev, r);
if (IS_ERR(lpwm->regs))
- return PTR_ERR(lpwm->regs);
-
- lpwm->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(lpwm->clk)) {
- dev_err(>dev, "failed to get PWM clock\n");
- return PTR_ERR(lpwm->clk);
+ return lpwm->regs;
+
+ if (info) {
+ lpwm->clk_rate = info->clk_rate;
+ } else {
+ lpwm->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(lpwm->clk)) {
+ dev_err(dev, "failed to get PWM clock\n");
+ return (void *)lpwm->clk;
+ }
+ lpwm->clk_rate = clk_get_rate(lpwm->clk);
}
- lpwm->chip.dev = >dev;
+ lpwm->chip.dev = dev;
lpwm->chip.ops = _lpss_ops;
lpwm->chip.base = -1;
lpwm->chip.npwm = 1;
ret = pwmchip_add(>chip);
if (ret) {
- dev_err(>dev, "failed to add PWM chip: %d\n", ret);
- return ret;
+ dev_err(dev, "failed to add PWM chip: %d\n", ret);
+ return ERR_PTR(ret);
}
- platform_set_drvdata(pdev, lpwm);
- return 0;
+ return lpwm;
}
-static int pwm_lpss_remove(struct platform_device *pdev)
+static int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
{
- struct pwm_lpss_chip *lpwm = platform_get_drvdata(pdev);
u32 ctrl;
ctrl = readl(lpwm->regs + PWM);
@@ -167,17 +175,107 @@ static int pwm_lpss_remove(struct platform_device *pdev)
return pwmchip_remove(>chip);
}
-static struct platform_driver pwm_lpss_driver = {
+static int pwm_lpss_probe_pci(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct pwm_lpss_boardinfo *info;
+ struct pwm_lpss_chip *lpwm;
+ int err;
+
+ err = pci_enable_device(pdev);
+ if (err < 0)
+ return err;
+
+ info = (struct pwm_lpss_boardinfo *)id->driver_data;
+ lpwm = pwm_lpss_probe(>dev, >resource[0], info);
+ if (IS_ERR(lpwm))
+ return PTR_ERR(lpwm);
+
+ pci_set_drvdata(pdev, lpwm);
+ return 0;
+}
+
+static void pwm_lpss_remove_pci(struct pci_dev *pdev)
+{
+ struct pwm_lpss_chip *lpwm = pci_get_drvdata(pdev);
+
+ pwm_lpss_remove(lpwm);
+ pci_disable_device(pdev);
+}
+
+static struct pci_device_id pwm_lpss_pci_ids[] = {
+
Re: Things I wish I'd known about Inotify
On 04/07/2014 11:31 AM, Jan Kara wrote: > On Sun 06-04-14 11:00:29, Michael Kerrisk (man-pages) wrote: >> On 04/04/2014 02:43 PM, Jan Kara wrote: >>> On Fri 04-04-14 09:35:50, Michael Kerrisk (man-pages) wrote: On 04/03/2014 10:52 PM, Jan Kara wrote: > On Thu 03-04-14 08:34:44, Michael Kerrisk (man-pages) wrote: >> >> [...] >> >>Dealing with rename() events >>The IN_MOVED_FROM and IN_MOVED_TO events that are generated by >>rename(2) are usually available as consecutive events when read‐ >>ing from the inotify file descriptor. However, this is not guar‐ >>anteed. If multiple processes are triggering events for moni‐ >>tored objects, then (on rare occasions) an arbitrary number of >>other events may appear between the IN_MOVED_FROM and IN_MOVED_TO >>events. >> >>Matching up the IN_MOVED_FROM and IN_MOVED_TO event pair gener‐ >>ated by rename(2) is thus inherently racy. (Don't forget that if >>an object is renamed outside of a monitored directory, there may >>not even be an IN_MOVED_TO event.) Heuristic approaches (e.g., >>assume the events are always consecutive) can be used to ensure a >>match in most cases, but will inevitably miss some cases, causing >>the application to perceive the IN_MOVED_FROM and IN_MOVED_TO >>events as being unrelated. If watch descriptors are destroyed >>and re-created as a result, then those watch descriptors will be >>inconsistent with the watch descriptors in any pending events. >>(Re-creating the inotify file descriptor and rebuilding the cache >>may be useful to deal with this scenario.) > Well, but there's 'cookie' value meant exactly for matching up > IN_MOVED_FROM and IN_MOVED_TO events. And 'cookie' is guaranteed to be > unique at least within the inotify instance (in fact currently it is > unique > within the whole system but I don't think we want to give that promise). Yes, that's already assumed by my discussion above (its described elsewhere in the page). But your comment makes me think I should add a few words to remind the reader of that fact. I'll do that. >>> Yes, that would be good. >>> But, the point is that even with the cookie, matching the events is nontrivial, since: * There may not even be an IN_MOVED_FROM event * There may be an arbitrary number of other events in between the IN_MOVED_FROM and the IN_MOVED_TO. Therefore, one has to use heuristic approaches such as "allow at least N millisconds" or "check the next N events" to see if there is an IN_MOVED_FROM that matches the IN_MOVED_TO. I can't see any way around that being inherently racy. (It's unfortunate that the kernel can't provide a guarantee that the two events are always consecutive, since that would simply user space's life considerably.) >> >>> Yeah, it's unpleasant but doing that would be quite costly/complex at the >>> kernel side. >> >> Yep, I imagined that was probably the reason. > I had a look into that code again and it's all designed around the fact > that there's a single inode to notify. If you liked to have atomic rename > notifications, you'd have to rewrite that to work with two inodes, finding > out whether these two inodes are actually watched by the same group or > not... Doable but complex. Alternatively you could just lock down the whole > notification subsystem while generating rename events. But that's rather > costly. Just that we have the complications written down somewhere in case > someone wants to look into this in future. > >>> And the race would in the worst case lead to application >>> thinking there's been file moved outside of watched area & a file moved >>> somewhere else inside the watched area. So the application will have to >>> possibly inspect that file. That doesn't seem too bad. >> >> It's actually very bad. See the text above. The point is that one likely >> treatment on an IN_MOVED_FROM event that has no IN_MOVED_TO is to remove >> the watches for the moved out subtree. If it turns out that this really >> was just a rename(), then on the IN_MOVED_TO, the watches will be recreated >> *with different watch descriptors*, thus invalidating the watch descriptors >> in any queued but as yet unprocessed inotify events. See what I mean? >> That's quite painful for user space. Sorry for the late follow-up > But if I understand it right, you loose only the information for recreated > watches. So you effectively loose all the information about what has > happened inside the subtree of moved directory (or what has happened with > the moved file). But since you think it's a file / dir moved from outside > of watched area, you have to fully rescan that file / dir
Re: [PATCH 3.14 00/23] 3.14.1-stable review
At Fri, 11 Apr 2014 17:46:55 -0600, Shuah Khan wrote: > > On 04/11/2014 10:11 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.1 release. > > There are 23 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Apr 13 16:11:46 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.1-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test systems. No dmesg regressions. All 3.10.37-rc1, 3.13.10-rc1, and 3.14.1-rc1 passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/1] X86: Probe for PIC and set legacy_pic appropriately
Probe for the existance of legacy PIC, if one does not exist, use the
null_legacy_pic.
This patch implements the proposal put forth by H. Peter Anvin
.
In version V1 of the patch, I had cleaned up the code based on comments from
Peter.
In this version of the patch, I have addressed additional comments from Peter.
Signed-off-by: K. Y. Srinivasan
---
arch/x86/kernel/cpu/mshyperv.c |2 --
arch/x86/kernel/i8259.c| 19 +++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 47359f7..9ca9587 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -133,8 +133,6 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
lapic_timer_frequency);
- printk(KERN_INFO "HyperV: Using null_legacy_pic\n");
- legacy_pic = _legacy_pic;
}
#endif
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 2e977b5..7f7bd02 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -299,11 +299,30 @@ static void unmask_8259A(void)
static void init_8259A(int auto_eoi)
{
unsigned long flags;
+ unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
+ unsigned char new_val;
i8259A_auto_eoi = auto_eoi;
raw_spin_lock_irqsave(_lock, flags);
+ /*
+* Check to see if we have a PIC.
+* Mask all except the cascade and read
+* back the value we just wrote. If we don't
+* have a PIC, we will read 0xff as opposed to the
+* value we wrote.
+*/
+ outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
+ outb(probe_val, PIC_MASTER_IMR);
+ new_val = inb(PIC_MASTER_IMR);
+ if (probe_val != new_val) {
+ printk(KERN_INFO "Using NULL legacy PIC\n");
+ legacy_pic = _legacy_pic;
+ raw_spin_unlock_irqrestore(_lock, flags);
+ return;
+ }
+
outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On Fri, Apr 11, 2014 at 2:50 PM, Linus Torvalds wrote: > On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst wrote: >> >> I haven't tested it recently but I do know it has worked on 64-bit >> kernels. There is no reason for it not to, the only thing not >> supported in long mode is vm86. 16-bit protected mode is unchanged. > > Afaik 64-bit windows doesn't support 16-bit binaries, so I just > assumed Wine wouldn't do it either on x86-64. Not for any real > technical reasons, though. > > HOWEVER. I'd like to hear something more definitive than "I haven't > tested recently". The "we don't break user space" is about having > actual real *users*, not about test programs. > > Are there people actually using 16-bit old windows programs under > wine? That's what matters. > > Linus I just verified that the game does still run on a 64-bit kernel (3.13.8-200.fc20.x86_64). It needed an older version of Wine, but that's a Wine regression and not kernel related. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ARM : DMA : remove useless information about DMA
Hi Nicolas, Your version is better. you tell me this in the former letters. So I am very sorry to forget to check that. May be I should remake this second patch to fit your change. What do you think about that patch? Liu Hua On 2014/4/12 11:12, Nicolas Pitre wrote: > On Fri, 11 Apr 2014, Liu Hua wrote: > >> Because commit e9da6e9905e6 has remove custom consistent dma >> region. So the related variable and document should be removed >> >> Signed-off-by: Liu Hua > > Acked-by: Nicolas Pitre > > Incidentally I sent an identical patch to RMK's patch system: > > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8023/1 > > Either version is fine with me. > > > Nicolas > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] phy: exynos5-usbdrd: Add facility to toggle vbus gpio on/off
On Wed, Apr 09, 2014 at 05:24:45PM +0530, Vivek Gautam wrote:
> Adding support to enable/disable VBUS hooked to a gpio
> to enable vbus supply on the port.
>
> Signed-off-by: Vivek Gautam
> ---
>
> Based on 'phy-exynos5-usbdrd' patches:
> [PATCH V4 0/5] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
> http://www.spinics.net/lists/linux-usb/msg105507.html
>
> drivers/phy/phy-exynos5-usbdrd.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
> b/drivers/phy/phy-exynos5-usbdrd.c
> index ff54a7c..5ca7485 100644
> --- a/drivers/phy/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/phy-exynos5-usbdrd.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -176,6 +177,7 @@ struct exynos5_usbdrd_phy {
> struct clk *ref_clk;
> unsigned long ref_rate;
> unsigned int refclk_reg;
> + int gpio;
> };
>
> #define to_usbdrd_phy(inst) \
> @@ -460,6 +462,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
> if (!IS_ERR(phy_drd->usb30_sclk))
> clk_prepare_enable(phy_drd->usb30_sclk);
>
> + /* Toggle VBUS gpio - on */
> + gpio_set_value(phy_drd->gpio, 1);
It seems like you'd be better off using a regulator_enable() call for
this.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/2] ARM : DMA : remove useless information about DMA
On Fri, 11 Apr 2014, Nicolas Pitre wrote: > On Fri, 11 Apr 2014, Liu Hua wrote: > > > Because commit e9da6e9905e6 has remove custom consistent dma > > region. So the related variable and document should be removed > > > > Signed-off-by: Liu Hua > > Acked-by: Nicolas Pitre > > Incidentally I sent an identical patch to RMK's patch system: > > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8023/1 > > Either version is fine with me. Actually mine is slightly better as I also removed the entry covering 0xff00 to 0xffbf which is no longer used either. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] change ARM linux memory layout to support 32 CPUs
On Fri, 11 Apr 2014, Liu Hua wrote: > Hi Nicolas or Russell, > > This patch series change fixmap mapping region to suppport 32 CPUs. > Because the "top_pmd" covers 0xfffe - 0x(2M). And part > is used by vector table. So I move this region down to 0xffc0 > - 0xffd. > > > I have tested the patches on arma9(2 CPUs) and arma15(16 CPUs) platforms > > BTW, As we know we can configure NR_CPUS up to 32. So we need 2048K > at most. But for ARM systems with less cpus, there is a waste > of virtual address. So should we change its size according to > NR_CPUS, as what MIPS linux does ? It is probably not worth the bother. We lived with this area reserved for static DMA mapping while there was no longer any DMA mapped there for quite a while. > > Changes from v1: > --- > - changed documentation for ARM linux memory layout. > - moved fixmap mapping region, not just extended. > > Liu Hua (2): > ARM : DMA : remove useless information about DMA > ARM : extend fixmap mapping region to support 32 CPUs > > Documentation/arm/memory.txt | 8 ++-- > arch/arm/include/asm/fixmap.h | 4 ++-- > arch/arm/include/asm/highmem.h | 1 + > arch/arm/include/asm/memory.h | 2 -- > arch/arm/mm/highmem.c | 10 +- > arch/arm/mm/mm.h | 7 +++ > arch/arm/mm/mmu.c | 4 > mm/highmem.c | 1 + > 8 files changed, 22 insertions(+), 15 deletions(-) > > -- > 1.9.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM : change fixmap mapping region to support 32 CPUs
On Fri, 11 Apr 2014, Liu Hua wrote:
> In 32-bit ARM systems, the fixmap mapping region can support
> no more than 14 CPUs(total: 896k; one CPU: 64K). And we can
> configure NR_CPUS up to 32. So there is a mismatch.
>
> This patch moves fixmapping region downwards to region
> 0xffc0-0xffe0 . Then the fixmap mapping region can
> support up to 32 CPUs.
>
> Signed-off-by: Liu Hua
Comments below.
> ---
> Documentation/arm/memory.txt | 2 +-
> arch/arm/include/asm/fixmap.h | 4 ++--
> arch/arm/include/asm/highmem.h | 1 +
> arch/arm/mm/highmem.c | 10 +-
> arch/arm/mm/mm.h | 7 +++
> arch/arm/mm/mmu.c | 4
> mm/highmem.c | 1 +
> 7 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
> index 8a361c0..4bca737 100644
> --- a/Documentation/arm/memory.txt
> +++ b/Documentation/arm/memory.txt
> @@ -41,7 +41,7 @@ fffe8000fffeDTCM mapping area for platforms
> with
> fffe fffe7fffITCM mapping area for platforms with
> ITCM mounted inside the CPU.
>
> -fff0 fffdFixmap mapping region. Addresses provided
> +ffc0 ffdfFixmap mapping region. Addresses provided
> by fix_to_virt() will be located here.
>
> ff00 ffbfReserved for future expansion of DMA
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index bbae919..014a70d 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -13,8 +13,8 @@
> * 0xfffe and 0xfffe.
> */
>
> -#define FIXADDR_START0xfff0UL
> -#define FIXADDR_TOP 0xfffeUL
> +#define FIXADDR_START0xffc0UL
> +#define FIXADDR_TOP 0xffe0UL
> #define FIXADDR_SIZE (FIXADDR_TOP - FIXADDR_START)
>
> #define FIX_KMAP_BEGIN 0
> diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
> index 91b99ab..5355795 100644
> --- a/arch/arm/include/asm/highmem.h
> +++ b/arch/arm/include/asm/highmem.h
> @@ -18,6 +18,7 @@
> } while (0)
>
> extern pte_t *pkmap_page_table;
> +extern pte_t *fixmap_page_table;
>
> extern void *kmap_high(struct page *page);
> extern void kunmap_high(struct page *page);
> diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
> index 21b9e1b..9bc8988 100644
> --- a/arch/arm/mm/highmem.c
> +++ b/arch/arm/mm/highmem.c
> @@ -69,14 +69,14 @@ void *kmap_atomic(struct page *page)
>* With debugging enabled, kunmap_atomic forces that entry to 0.
>* Make sure it was indeed properly unmapped.
>*/
> - BUG_ON(!pte_none(get_top_pte(vaddr)));
> + BUG_ON(!pte_none(*(fixmap_page_table + idx)));
> #endif
> /*
>* When debugging is off, kunmap_atomic leaves the previous mapping
>* in place, so the contained TLB flush ensures the TLB is updated
>* with the new mapping.
>*/
> - set_top_pte(vaddr, mk_pte(page, kmap_prot));
> + set_fixmap_pte(idx, mk_pte(page, kmap_prot));
>
> return (void *)vaddr;
> }
> @@ -95,7 +95,7 @@ void __kunmap_atomic(void *kvaddr)
> __cpuc_flush_dcache_area((void *)vaddr, PAGE_SIZE);
> #ifdef CONFIG_DEBUG_HIGHMEM
> BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> - set_top_pte(vaddr, __pte(0));
> + set_fixmap_pte(idx, __pte(0));
> #else
> (void) idx; /* to kill a warning */
> #endif
> @@ -119,9 +119,9 @@ void *kmap_atomic_pfn(unsigned long pfn)
> idx = type + KM_TYPE_NR * smp_processor_id();
> vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> #ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(get_top_pte(vaddr)));
> + BUG_ON(!pte_none(*(fixmap_page_table + idx)));
> #endif
> - set_top_pte(vaddr, pfn_pte(pfn, kmap_prot));
> + set_fixmap_pte(idx, pfn_pte(pfn, kmap_prot));
>
> return (void *)vaddr;
> }
> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
> index 7ea641b..3460d73 100644
> --- a/arch/arm/mm/mm.h
> +++ b/arch/arm/mm/mm.h
> @@ -1,6 +1,7 @@
> #ifdef CONFIG_MMU
> #include
> #include
> +#include
>
> /* the upper-most page table pointer */
> extern pmd_t *top_pmd;
> @@ -25,6 +26,12 @@ static inline void set_top_pte(unsigned long va, pte_t pte)
> local_flush_tlb_kernel_page(va);
> }
>
> +static inline void set_fixmap_pte(int idx, pte_t pte)
> +{
> + unsigned long vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> + set_pte_ext(fixmap_page_table + idx, pte, 0);
> + local_flush_tlb_kernel_page(vaddr);
> +}
This has no other users than the code in highmem.c so it probably should
live there.
Other than that...
Acked-by: Nicolas Pitre
> static inline pte_t get_top_pte(unsigned long va)
> {
> pte_t *ptep = pte_offset_kernel(top_pmd, va);
>
[PATCH v2] ipc,shm: disable shmmax and shmall by default
From: Davidlohr Bueso
The default size for shmmax is, and always has been, 32Mb.
Today, in the XXI century, it seems that this value is rather small,
making users have to increase it via sysctl, which can cause
unnecessary work and userspace application workarounds[1].
Instead of choosing yet another arbitrary value, larger than 32Mb,
this patch disables the use of both shmmax and shmall by default,
allowing users to create segments of unlimited sizes. Users and
applications that already explicitly set these values through sysctl
are left untouched, and thus does not change any of the behavior.
So a value of 0 bytes or pages, for shmmax and shmall, respectively,
implies unlimited memory, as opposed to disabling sysv shared memory.
This is safe as 0 cannot possibly be used previously as SHMMIN is
hardcoded to 1 and cannot be modified.
This change allows Linux to treat shm just as regular anonymous memory.
One important difference between them, though, is handling out-of-memory
conditions: as opposed to regular anon memory, the OOM killer will not
free the memory as it is shm, allowing users to potentially abuse this.
To overcome this situation, the shm_rmid_forced option must be enabled.
[1]: http://rhaas.blogspot.com/2012/06/absurd-shared-memory-limits.html
Signed-off-by: Davidlohr Bueso
Acked-by: KAMEZAWA Hiroyuki
Acked-by: KOSAKI Motohiro
---
Changes from v1:
- Respect SHMMIN even when shmmax is 0 (unlimited).
This fixes the shmget02 test that broke in v1. (per Manfred)
- Update changelog regarding OOM description (per Kosaki)
include/linux/shm.h | 2 +-
include/uapi/linux/shm.h | 8
ipc/shm.c| 6 --
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..0ca06a3 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -4,7 +4,7 @@
#include
#include
-#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
+#define SHMALL 0 /* max shm system wide (pages) */
#include
struct shmid_kernel /* private to the kernel */
{
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index 78b6941..5f0ef28 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -9,14 +9,14 @@
/*
* SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
- * be increased by sysctl
+ * be increased by sysctl. By default, disable SHMMAX and SHMALL with
+ * 0 bytes, thus allowing processes to have unlimited shared memory.
*/
-
-#define SHMMAX 0x200/* max shared seg size (bytes) */
+#define SHMMAX 0/* max shared seg size (bytes) */
#define SHMMIN 1/* min shared seg size (bytes) */
#define SHMMNI 4096 /* max num of segs system wide */
#ifndef __KERNEL__
-#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
+#define SHMALL 0
#endif
#define SHMSEG SHMMNI /* max shared segs per process */
diff --git a/ipc/shm.c b/ipc/shm.c
index 7645961..8630561 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -490,10 +490,12 @@ static int newseg(struct ipc_namespace *ns, struct
ipc_params *params)
int id;
vm_flags_t acctflag = 0;
- if (size < SHMMIN || size > ns->shm_ctlmax)
+ if (size < SHMMIN ||
+ (ns->shm_ctlmax && size > ns->shm_ctlmax))
return -EINVAL;
- if (ns->shm_tot + numpages > ns->shm_ctlall)
+ if (ns->shm_ctlall &&
+ ns->shm_tot + numpages > ns->shm_ctlall)
return -ENOSPC;
shp = ipc_rcu_alloc(sizeof(*shp));
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ARM : DMA : remove useless information about DMA
On Fri, 11 Apr 2014, Liu Hua wrote: > Because commit e9da6e9905e6 has remove custom consistent dma > region. So the related variable and document should be removed > > Signed-off-by: Liu Hua Acked-by: Nicolas Pitre Incidentally I sent an identical patch to RMK's patch system: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8023/1 Either version is fine with me. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver
This patch adds documentation for APM X-Gene SoC ethernet DTS binding.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
.../devicetree/bindings/net/apm-xgene-enet.txt | 46
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
new file mode 100644
index 000..0c983e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -0,0 +1,46 @@
+APM X-Gene SoC Ethernet nodes
+
+Ethernet nodes are defined to describe on-chip ethernet interfaces in
+APM X-Gene SoC.
+
+Required properties:
+- compatible : Should be "apm,xgene-enet"
+- reg : First resource is the ethernet base register set
+ Second resource is the ring base register set
+ Third resource is the ring command register set
+- interrupts : Ethernet main interrupt
+- clocks : Reference to the clock entry.
+- local-mac-address: Ethernet MAC address.
+- phy-addr : Ethernet MII phy address.
+- phy-mode : Ethernet MII mode.
+
+Optional properties:
+- status : Should be "ok" or "disabled" for enabled/disabled.
+ Default is "ok".
+
+Example:
+ menetclk: menetclk {
+ compatible = "apm,xgene-device-clock";
+ clock-output-names = "menetclk";
+ status = "ok";
+ };
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+ interrupts = <0x0 0x3c 0x4>;
+ clocks = < 0>;
+ local-mac-address = [00 01 73 00 00 01];
+ phy-addr = <3>;
+ phy-mode = "rgmii";
+ };
+
+
+/* Board-specific peripheral configurations */
+
+ {
+status = "ok";
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] dts: Add bindings for APM X-Gene SoC ethernet driver
This patch adds bindings for APM X-Gene SoC ethernet driver.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
arch/arm64/boot/dts/apm-mustang.dts |4
arch/arm64/boot/dts/apm-storm.dtsi | 18 +++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-mustang.dts
b/arch/arm64/boot/dts/apm-mustang.dts
index 1247ca1..e2fb1ef 100644
--- a/arch/arm64/boot/dts/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -24,3 +24,7 @@
reg = < 0x1 0x 0x0 0x8000 >; /* Updated by
bootloader */
};
};
+
+ {
+ status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index 93f4b2d..6b2b7f9 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -167,14 +167,13 @@
clock-output-names = "ethclk";
};
- eth8clk: eth8clk {
+ menetclk: menetclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = < 0>;
- clock-names = "eth8clk";
reg = <0x0 0x1702C000 0x0 0x1000>;
reg-names = "csr-reg";
- clock-output-names = "eth8clk";
+ clock-output-names = "menetclk";
};
sataphy1clk: sataphy1clk@1f21c000 {
@@ -339,5 +338,18 @@
phys = < 0>;
phy-names = "sata-phy";
};
+
+ menet: ethernet@1702 {
+ compatible = "apm,xgene-enet";
+ status = "disabled";
+ reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+ interrupts = <0x0 0x3c 0x4>;
+ clocks = < 0>;
+ local-mac-address = [00 01 73 00 00 01];
+ phy-addr = <3>;
+ phy-mode = "rgmii";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver
This patch adds a MAINTAINERS entry for APM X-Gene SoC ethernet driver. Signed-off-by: Iyappan Subramanian Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 11b3937..bc32a01 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -686,6 +686,14 @@ S: Maintained F: drivers/net/appletalk/ F: net/appletalk/ +APPLIED MICRO (APM) X-GENE SOC ETHERNET DRIVER +M: Iyappan Subramanian +M: Keyur Chudgar +M: Ravi Patel +S: Maintained +F: drivers/net/ethernet/apm/xgene +F: Documentation/devicetree/bindings/net/apm-xgene-enet.txt + APTINA CAMERA SENSOR PLL M: Laurent Pinchart L: linux-me...@vger.kernel.org -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] net: Add APM X-Gene SoC Ethernet driver support
This patch series adds support for the APM X-Gene SoC Ethernet driver. v2 * Completely redesigned ethernet driver * Added support to work with big endian kernel * Renamed dtb phyid entry to phy_addr * Changed dtb local-mac-address entry to byte string format * Renamed dtb eth8clk entry to menetclk v1 * Initial version Signed-off-by: Iyappan Subramanian Signed-off-by: Ravi Patel Signed-off-by: Keyur Chudgar --- Iyappan Subramanian (4): MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver dts: Add bindings for APM X-Gene SoC ethernet driver drivers: net: Add APM X-Gene SoC ethernet driver support. .../devicetree/bindings/net/apm-xgene-enet.txt | 46 + MAINTAINERS|8 + arch/arm64/boot/dts/apm-mustang.dts|4 + arch/arm64/boot/dts/apm-storm.dtsi | 18 +- drivers/net/ethernet/Kconfig |1 + drivers/net/ethernet/Makefile |1 + drivers/net/ethernet/apm/Kconfig |1 + drivers/net/ethernet/apm/Makefile |5 + drivers/net/ethernet/apm/xgene/Kconfig | 10 + drivers/net/ethernet/apm/xgene/Makefile|6 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 829 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 383 drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 927 drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 153 14 files changed, 2389 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt create mode 100644 drivers/net/ethernet/apm/Kconfig create mode 100644 drivers/net/ethernet/apm/Makefile create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig create mode 100644 drivers/net/ethernet/apm/xgene/Makefile create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V1 1/1] X86: Probe for PIC and set legacy_pic appropriately
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Friday, April 11, 2014 4:59 PM
> To: KY Srinivasan; x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> jbeul...@suse.com
> Subject: Re: [PATCH V1 1/1] X86: Probe for PIC and set legacy_pic
> appropriately
>
> On 04/11/2014 05:50 PM, K. Y. Srinivasan wrote:
> >
> > + /*
> > +* Check to see if we have a PIC.
> > +* Mask all except the cascade and read
> > +* back the value we just wrote. If we don't
> > +* have a PIC, we will read 0xff as opposed to the
> > +* value we wrote.
> > +*/
> > + outb(probe_val, PIC_MASTER_IMR);
> > + probe_val = inb(PIC_MASTER_IMR);
> > + if (probe_val == 0xff) {
> > + printk(KERN_INFO "Using NULL legacy PIC\n");
> > + legacy_pic = _legacy_pic;
> > + raw_spin_unlock_irqrestore(_lock, flags);
> > + return;
> > + }
> > +
> > outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
> > outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
> >
>
> Again, I would do at least the slave masking above the probe.
>
> Also, I would compare to make sure we get the probe_val back and compare
> with != instead of comparing with ==.
Will do.
Thanks,
K. Y
Re: [PATCH 3.14 00/23] 3.14.1-stable review
On Fri, Apr 11, 2014 at 05:46:55PM -0600, Shuah Khan wrote: > On 04/11/2014 10:11 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.1 release. > > There are 23 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Apr 13 16:11:46 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.1-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test systems. No dmesg regressions. Thanks for testing all 3 of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 000/134] 3.4.87-stable review
On Sat, Apr 12, 2014 at 10:01:08AM +0900, Satoru Takeuchi wrote: > At Thu, 10 Apr 2014 13:56:29 -0600, > Shuah Khan wrote: > > > > On 04/09/2014 09:21 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.4.87 release. > > > There are 134 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sat Apr 12 03:22:28 UTC 2014. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.87-rc1.gz > > > and the diffstat can be found below. > > > > > > > Compiled and booted on my test systems. No dmesg regressions. > > This kernel passed my test. > > - Test Cases: >- Build this kernel. >- Boot this kernel. >- Build the latest mainline kernel with this kernel. > > - Test Tool: >https://github.com/satoru-takeuchi/test-linux-stable > > - Test Result (kernel .config, ktest config and test log): >http://satoru-takeuchi.org/test-linux-stable/results/- datetime>.tar.xz > > - Build Environment: >- OS: Debian Jessy x86_64 >- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >- memory: 8GB > > - Test Target Environment: >- Debian Jessy x86_64 (KVM guest on the Build Environment) >- # of vCPU: 2 >- memory: 2GB Wonderful, thanks for testing. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/23] 3.14.1-stable review
On Fri, Apr 11, 2014 at 02:49:42PM -0700, Guenter Roeck wrote: > On 04/11/2014 09:11 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.14.1 release. > > There are 23 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Apr 13 16:11:46 UTC 2014. > > Anything received after that time might be too late. > > Build results: > total: 126 pass: 121 skipped: 4 fail: 1 > > Failing build is powerpc:allmodconfig. Error log: > > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org > backwards > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 > > Qemu tests all passed. Results match the build results from 3.14, and are > therefore as expected. > > Details are available at http://server.roeck-us.net:8010/builders. Thanks for testing all 3 of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Btrfs part two
Hi Chris, On Fri, 11 Apr 2014 12:50:26 PM Chris Mason wrote: > The most important changes here are from Josef, fixing a btrfs > regression in 3.14 that can cause corruptions in the extent allocation > tree when snapshots are in use. Will these regression fixes go to stable too? cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC signature.asc Description: This is a digitally signed message part.
[PATCH] video: bf54x-lq043fb: fix build error
From: Steven Miao should include linux/gpio.h Signed-off-by: Steven Miao --- drivers/video/bf54x-lq043fb.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c index 42b8f9d..d2b54f1 100644 --- a/drivers/video/bf54x-lq043fb.c +++ b/drivers/video/bf54x-lq043fb.c @@ -49,6 +49,7 @@ #include #include #include +#include #include #include -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] spi: bfin5xx: fix build error
From: Steven Miao should include linux/gpio.h Signed-off-by: Steven Miao --- drivers/spi/spi-bfin5xx.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c index 55e57c3..ebf720b 100644 --- a/drivers/spi/spi-bfin5xx.c +++ b/drivers/spi/spi-bfin5xx.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[uclinux-dist-devel] [GIT PULL] Blackfin updates for 3.15
please pull blackfin updates for Linux 3.15, code cleanup, some previously ignored patches, and bug fixes. The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git tags/blackfin-for-linus for you to fetch changes up to c4a2c58d20953ff1080f50f705cdd952f6d301b2: blackfin: cleanup board files (2014-04-12 08:48:01 +0800) blackfin updates for Linux 3.15 Paul Bolle (7): blackfin: bf60x: fix typo "CONFIG_PM_BFIN_WAKE_PA15_POL" blackfin: Remove GENERIC_GPIO config option again Blackfin: remove "config IP_CHECKSUM_L1" blackfin: bf537: fix typo "CONFIG_SND_SOC_ADV80X_MODULE" Blackfin: bf537: rename ad2s120x ->ad2s1200 Blackfin: bf537: rename "CONFIG_AD7314" Blackfin: bf537: rename "CONFIG_ADT75" Sonic Zhang (2): bfin_crc: Move architecture independant crc header file out of the blackfin folder. blackfin: dma: current count mmr is read only Steven Miao (4): blackfin: portmux: cleanup head file bf54x: drop unuesd HOST status,control,timeout registers bit define macros bf609: clock: drop unused clock bit set/clear functions blackfin: cleanup board files Thomas Gleixner (1): blackfin:Use generic /proc/interrupts implementation arch/blackfin/Kconfig| 12 +- arch/blackfin/include/asm/bfin_crc.h | 125 --- arch/blackfin/include/asm/dma.h |2 - arch/blackfin/include/asm/portmux.h | 10 +- arch/blackfin/kernel/irqchip.c | 39 +- arch/blackfin/mach-bf518/boards/ezbrd.c | 87 +++-- arch/blackfin/mach-bf518/boards/tcm-bf518.c | 64 ++-- arch/blackfin/mach-bf527/boards/ad7160eval.c | 71 ++-- arch/blackfin/mach-bf527/boards/cm_bf527.c | 91 +++-- arch/blackfin/mach-bf527/boards/ezbrd.c | 76 ++-- arch/blackfin/mach-bf527/boards/ezkit.c | 139 --- arch/blackfin/mach-bf527/boards/tll6527m.c | 91 +++-- arch/blackfin/mach-bf533/boards/H8606.c | 46 +-- arch/blackfin/mach-bf533/boards/blackstamp.c | 44 +-- arch/blackfin/mach-bf533/boards/cm_bf533.c | 54 +-- arch/blackfin/mach-bf533/boards/ezkit.c | 56 +-- arch/blackfin/mach-bf533/boards/ip0x.c | 26 +- arch/blackfin/mach-bf533/boards/stamp.c | 118 +++--- arch/blackfin/mach-bf537/boards/cm_bf537e.c | 82 ++--- arch/blackfin/mach-bf537/boards/cm_bf537u.c | 70 ++-- arch/blackfin/mach-bf537/boards/dnp5370.c| 32 +- arch/blackfin/mach-bf537/boards/minotaur.c | 50 ++- arch/blackfin/mach-bf537/boards/pnav10.c | 55 ++- arch/blackfin/mach-bf537/boards/stamp.c | 425 ++ arch/blackfin/mach-bf537/boards/tcm_bf537.c | 70 ++-- arch/blackfin/mach-bf538/boards/ezkit.c | 62 ++-- arch/blackfin/mach-bf548/boards/cm_bf548.c | 78 ++-- arch/blackfin/mach-bf548/boards/ezkit.c | 136 --- arch/blackfin/mach-bf548/include/mach/defBF544.h | 30 -- arch/blackfin/mach-bf548/include/mach/defBF547.h | 30 -- arch/blackfin/mach-bf561/boards/acvilon.c| 28 +- arch/blackfin/mach-bf561/boards/cm_bf561.c | 56 +-- arch/blackfin/mach-bf561/boards/ezkit.c | 74 ++-- arch/blackfin/mach-bf561/boards/tepla.c |8 +- arch/blackfin/mach-bf609/boards/ezkit.c | 131 +++ arch/blackfin/mach-bf609/clock.c | 18 - arch/blackfin/mach-bf609/pm.c|2 +- 37 files changed, 1115 insertions(+), 1473 deletions(-) delete mode 100644 arch/blackfin/include/asm/bfin_crc.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] iproute2 3.14.0
Time for the release of iproute2 for 3.14 (aka Shuffling Zombie Juror) The main new features are: * ss gets lots of attention * Support for PIE qdisc * A bunch of HTB related changes from Eric * better bonding support * Lots of little corrections and build fixes Source: http://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-3.14.0.tar.gz Repository: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git Report problems (or enhancements) to the net...@vger.kernel.org mailing list. --- Adam Borowski (1): ip: fix build failure if time_t is not long int Alexander Duyck (1): iproute2: act_ipt fix xtables breakage on older versions. Amerigo Wang (1): iptunnel: check SIT_ISATAP flag only for SIT tunnel Andreas Henriksson (3): iproute2: fix build failure on sparc due to -Wformat and tv_usec ss: avoid passing negative numbers to malloc Andrey Vagin (5): ip: set the close-on-exec flag for descriptors ss: handle socket diag request in a separate function ss: create a function to print info about netlink sockets ss: show destination address for netlink sockets ss: Get netlink sockets info via sock-diag (v2) Arvid Brodin (1): ip: Add HSR support Atzm Watanabe (1): vxlan: Allow setting destination to unicast address. Christoph Paasch (3): tcp_metrics: Rename addr to daddr and add local variable tcp_metrics: Display source-address tcp_metrics: Allow removal based on the source-IP Christophe Gouault (1): xfrm: enable to set non-wildcard mark 0 on SAs and SPs Cong Wang (1): add quickack option to ip route Daniel Borkmann (2): ip: ipv6: add tokenized interface identifier support tc: add cls_bpf frontend David L Stevens (1): iproute2: support NTF_ROUTER flag in VXLAN fdb entries David Stevens (1): iproute2: generalize VXLAN forwarding tables Eric Dumazet (10): ss: add fastopen support htb: report overhead attribute get_rate: detect 32bit overflows ss: add more TCP_INFO components pkt_sched: fq: Fair Queue packet scheduler tc: support TCA_STATS_RATE_EST64 htb: add support for direct_qlen attribute htb: support 64bit rates tc: more user friendly rates FX Le Bail (1): ss: display interface name as zone index when needed Fan Du (1): xfrm: use memcpy to suppress gcc phony buffer overflow warning. Hangbin Liu (3): ipaddrlabel: use uint32_t instead of int32_t iptunnel: Allow GRE_KEY for vti interface Heiner Kallweit (1): ip: officially support flag mngtmpaddr also for "ip addr del" Hiroaki SHIMODA (1): htb: Move direct_qlen code part to htb_parse_opt(). Jamal Hadi Salim (8): tc: introduce simple action action: typo nat fix skbedit to default to pipe skbedit print missing metadata policer - retire old syntax simple print newline allow batch gets of actions dont skip action order Jesper Dangaard Brouer (1): linklayer interface between kernel and tc/userspace Jiri Pirko (5): iplink: add support for bonding netlink add support for extended ifa_flags add support for IFA_F_MANAGETEMPADDR introduce support for slave info data iplink: add support for bonding slave John Fastabend (2): iproute2: bridge: fix 'bridge link' setlink/getlink parsing iproute2: add man page for mqprio JunweiZhang (1): ipbatch: fix use of 'ip netns exec' Kamil Rytarowski (1): iproute2 patch against GCC 4.8.0 Kusanagi Kouichi (1): veth: Handle flags correctry Lutz Jaenicke (1): macvlan: fix typo in macvlan_print_opt() Martin Schwenke (1): ip: Add label option to ip monitor Masatake YAMATO (7): ss: handle seqpacket type of unix domain socket ss: enable query by type in unix domain related socket ss: add unix_seqpacket to the help message and the man page genl: fix a typo in help message of ctrl iproute2: use named constants instead of number literals to fill rtnl_rttable_hash iproute: Show default type, table, proto and scope of route Michal Kubeček (3): iplink_bond: fix arp_all_targets parameter name in output iplink_bond: fix parameter value matching iplink_bond_slave: show mii_status only once Mike Rapoport (1): bridge: fix reporting of IPv6 addresses Mythili Prabhu (1): PIE: Add man page Nicolas Dichtel (9): ip: add missing help about mode argument ip/xfrm: all to set flag XFRM_SA_XFLAG_DONT_ENCAP_DSCP ipnetconf: by default dump all entries ss: allow to retrieve AF_PACKET info via netlink man: describe --bpf option of ss ipadress: fix display of IPv6 peer address ip: allow to specify mode for sit tunnels ipnetns: fix ip batch mode when using 'netns exec' iplink: update available type list Nigel Kukard (1): Fix tc stats when using
Re: [PATCH 3.4 000/134] 3.4.87-stable review
At Thu, 10 Apr 2014 13:56:29 -0600, Shuah Khan wrote: > > On 04/09/2014 09:21 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.87 release. > > There are 134 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Apr 12 03:22:28 UTC 2014. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.87-rc1.gz > > and the diffstat can be found below. > > > > Compiled and booted on my test systems. No dmesg regressions. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fwserial: (unexhaustive) coding style review
On Sat, Apr 12, 2014 at 01:41:01AM +0200, Dominique van den Broeck wrote: > From: Dominique van den Broeck > fwserial: (unexhaustive) coding style review No need for the From: line here, or the extra subject line. > > linux-next commit 88a8e0969581869c742a9957ddcfe43063dff687 This isn't needed either. > > Style-only modifications to make checkpatch.pl --file --strict a bit > happier. > I fixed only what was trivial, such as parenthesis alignments (one of > them, > at fwserial.c:1349, couldn't be easily replaced by something better, > though). > However, I did not comment by myself issues regarding spinlocks or > memory > barriers. Odd linewrapping. > > This is my very first patch. Please be indulgent and forgive my eventual > mistakes. I did that to start contributing to linux kernel, but also > as task #10 of the Eudyptula Challenge ( http://eudyptula-challenge.org/ > ). This isn't needed at all, don't put it in the changelog area. > > Signed-off-by: Dominique van den Broeck > --- > diff -upr a/drivers/staging/fwserial/dma_fifo.c > b/drivers/staging/fwserial/dma_fifo.c > --- a/drivers/staging/fwserial/dma_fifo.c 2014-04-11 20:48:20.813667706 > +0200 > +++ b/drivers/staging/fwserial/dma_fifo.c 2014-04-11 20:47:49.700058306 > +0200 The patch is line-wrapped and can't be applied :( > @@ -12,10 +12,6 @@ > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > Foundation, > - * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > */ You are fixing a lot of different things here. Patches need to do only one thing at a time. For different coding style cleanups, do it one patch per "thing", and this will be a few patches at the least. So, can you fix this all up and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] staging: vt6655: removed incorrect casting in iwctl.c
This patch fixes the following type of sparse warning:
drivers/staging/vt6655/iwctl.c:1846:35: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/iwctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c
index ac3fc16..5e25535 100644
--- a/drivers/staging/vt6655/iwctl.c
+++ b/drivers/staging/vt6655/iwctl.c
@@ -1843,7 +1843,7 @@ int iwctl_siwencodeext(struct net_device *dev,
PRINT_K("SIOCSIWENCODEEXT.. \n");
blen = sizeof(*param);
- buf = kmalloc((int)blen, (int)GFP_KERNEL);
+ buf = kmalloc((int)blen, GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;
memset(buf, 0, blen);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] remove wrong cast of gfp_t flags
Hi, > > thanks for your review. > > Attached second version of this series. > > I don't understand what the [WIP] marking is. Please just resend these > as "real" patches if you feel they are ready to be merged. If we have > issues with them, we will be sure to let you know :) I removed it. Bye, Silvio v3: * no 'WIP'! Don't do that! v2: * signed-off and message are not the same address Silvio Fricke (3): staging: vt6655: removed incorrect casting in wpactl.c staging: vt6655: removed incorrect casting in ioctl.c staging: vt6655: removed incorrect casting in iwctl.c drivers/staging/vt6655/ioctl.c | 6 -- drivers/staging/vt6655/iwctl.c | 2 +- drivers/staging/vt6655/wpactl.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] staging: vt6655: removed incorrect casting in ioctl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/ioctl.c:308:104: warning: cast from restricted gfp_t
drivers/staging/vt6655/ioctl.c:579:109: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/ioctl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/ioctl.c b/drivers/staging/vt6655/ioctl.c
index b5cd2e4..1de5d2c9 100644
--- a/drivers/staging/vt6655/ioctl.c
+++ b/drivers/staging/vt6655/ioctl.c
@@ -305,7 +305,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)), (int)GFP_ATOMIC);
+ pList = (PSBSSIDList)kmalloc(sizeof(SBSSIDList) + (sList.uItem
* sizeof(SBSSIDItem)),
+GFP_ATOMIC);
if (pList == NULL) {
result = -ENOMEM;
break;
@@ -576,7 +577,8 @@ int private_ioctl(PSDevice pDevice, struct ifreq *rq)
result = -EINVAL;
break;
}
- pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)), (int)GFP_ATOMIC);
+ pNodeList = (PSNodeList)kmalloc(sizeof(SNodeList) +
(sNodeList.uItem * sizeof(SNodeItem)),
+ GFP_ATOMIC);
if (pNodeList == NULL) {
result = -ENOMEM;
break;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] staging: vt6655: removed incorrect casting in wpactl.c
This patch fixes the following type of sparse warnings:
drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
Signed-off-by: Silvio Fricke
---
drivers/staging/vt6655/wpactl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index d17224f..4745429 100644
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -593,7 +593,7 @@ static int wpa_get_scan(PSDevice pDevice,
unsigned char *ptempBSS;
- ptempBSS = kmalloc(sizeof(KnownBSS), (int)GFP_ATOMIC);
+ ptempBSS = kmalloc(sizeof(KnownBSS), GFP_ATOMIC);
if (ptempBSS == NULL) {
printk(KERN_ERR "bubble sort kmalloc memory fail@@@\n");
@@ -635,7 +635,7 @@ static int wpa_get_scan(PSDevice pDevice,
count++;
}
- pBuf = kcalloc(count, sizeof(struct viawget_scan_result),
(int)GFP_ATOMIC);
+ pBuf = kcalloc(count, sizeof(struct viawget_scan_result), GFP_ATOMIC);
if (pBuf == NULL) {
ret = -ENOMEM;
@@ -857,7 +857,7 @@ int wpa_ioctl(PSDevice pDevice, struct iw_point *p)
p->length > VIAWGET_WPA_MAX_BUF_SIZE || !p->pointer)
return -EINVAL;
- param = kmalloc((int)p->length, (int)GFP_KERNEL);
+ param = kmalloc((int)p->length, GFP_KERNEL);
if (param == NULL)
return -ENOMEM;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-scsi: Skip setting affinity on uninitialized vq
Il 11/04/2014 03:23, Fam Zheng ha scritto:
virtscsi_init calls virtscsi_remove_vqs on err, even before initializing
the vqs. The latter calls virtscsi_set_affinity, so let's check the
pointer there before setting affinity on it.
This fixes a panic when setting device's num_queues=2 on RHEL 6.5:
qemu-system-x86_64 ... \
-device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \
-drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \
-device scsi-hd,drive=drive-scsi-disk,...
[0.354734] scsi0 : Virtio SCSI HBA
[0.379504] BUG: unable to handle kernel NULL pointer dereference at
0020
[0.380141] IP: [] __virtscsi_set_affinity+0x4f/0x120
[0.380141] PGD 0
[0.380141] Oops: [#1] SMP
[0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5
[0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[0.380141] task: 88003c9f ti: 88003c9f8000 task.ti:
88003c9f8000
[0.380141] RIP: 0010:[] []
__virtscsi_set_affinity+0x4f/0x120
[0.380141] RSP: :88003c9f9c08 EFLAGS: 00010256
[0.380141] RAX: RBX: 88003c3a9d40 RCX: 1070
[0.380141] RDX: 0002 RSI: RDI:
[0.380141] RBP: 88003c9f9c28 R08: 000136c0 R09: 88003c801c00
[0.380141] R10: 81475229 R11: 0008 R12:
[0.380141] R13: 81cc7ca8 R14: 88003cac3d40 R15: 88003cac37a0
[0.380141] FS: () GS:88003e40()
knlGS:
[0.380141] CS: 0010 DS: ES: CR0: 8005003b
[0.380141] CR2: 0020 CR3: 01c0e000 CR4: 06f0
[0.380141] Stack:
[0.380141] 88003c3a9d40 88003cac3d80
88003cac3d40
[0.380141] 88003c9f9c48 814742e8 88003c26d000
88003c26d000
[0.380141] 88003c9f9c68 81474321 88003c26d000
88003c3a9d40
[0.380141] Call Trace:
[0.380141] [] virtscsi_set_affinity+0x28/0x40
[0.380141] [] virtscsi_remove_vqs+0x21/0x50
[0.380141] [] virtscsi_init+0x91/0x240
[0.380141] [] ? vp_get+0x50/0x70
[0.380141] [] virtscsi_probe+0xf4/0x280
[0.380141] [] virtio_dev_probe+0xe5/0x140
[0.380141] [] driver_probe_device+0x89/0x230
[0.380141] [] __driver_attach+0x9b/0xa0
[0.380141] [] ? driver_probe_device+0x230/0x230
[0.380141] [] ? driver_probe_device+0x230/0x230
[0.380141] [] bus_for_each_dev+0x8c/0xb0
[0.380141] [] driver_attach+0x19/0x20
[0.380141] [] bus_add_driver+0x198/0x220
[0.380141] [] driver_register+0x5f/0xf0
[0.380141] [] ? spi_transport_init+0x79/0x79
[0.380141] [] register_virtio_driver+0x1b/0x30
[0.380141] [] init+0x88/0xd6
[0.380141] [] ? scsi_init_procfs+0x5b/0x5b
[0.380141] [] do_one_initcall+0x7f/0x10a
[0.380141] [] kernel_init_freeable+0x14a/0x1de
[0.380141] [] ? kernel_init_freeable+0x1de/0x1de
[0.380141] [] ? rest_init+0x80/0x80
[0.380141] [] kernel_init+0x9/0xf0
[0.380141] [] ret_from_fork+0x7c/0xb0
[0.380141] [] ? rest_init+0x80/0x80
[0.380141] RIP [] __virtscsi_set_affinity+0x4f/0x120
[0.380141] RSP
[0.380141] CR2: 0020
[0.380141] ---[ end trace 8074b70c3d5e1d73 ]---
[0.475018] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
[0.475018]
[0.475068] Kernel Offset: 0x0 from 0x8100 (relocation range:
0x8000-0x9fff)
[0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
Signed-off-by: Fam Zheng
---
drivers/scsi/virtio_scsi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..3019267 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -750,8 +750,12 @@ static void __virtscsi_set_affinity(struct virtio_scsi
*vscsi, bool affinity)
vscsi->affinity_hint_set = true;
} else {
- for (i = 0; i < vscsi->num_queues; i++)
+ for (i = 0; i < vscsi->num_queues; i++) {
+ if (!vscsi->req_vqs[i].vq) {
+ continue;
+ }
virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
+ }
vscsi->affinity_hint_set = false;
}
Fam, please send v2 with "Cc: sta...@vger.kernel.org" in the commit
message and my Acked-by.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cryogenic: Enabling Power-Aware Applications on Linux
On Sat, 12 Apr 2014, Christian Grothoff wrote: On 04/12/2014 12:05 AM, Pavel Machek wrote: Hi! Cryogenic is the result of my Master's Thesis, completed at the Technical University of Munich under the supervision of Christian Grothoff. You can find more information about Cryogenic at https://gnunet.org/cryogenic Hmm, but the API needs redoing, anyway, fcntl()? Depends --- while I like the idea, I did not hear enough to be certain that having this feature embedded in such a non-modular way was already the consensus (and I do not see a reasonable way to change the API this way while maintaining the modularity of the current code). hpa has a good track record for things like this, and there is very little desire in Linux for things to be kept as an optional add-on module (and cgroups is a very pointed example of what happens if a capability that people wants gets ignored). this sort of capability is something that is very desirable, there are many people making attempts to provide this sort of event consolidation. So I think it's _very_ safe to say that if this is accepted, it will be a change to the core, not just a loadable module. This means that you need to go through the work hpa was pointing you at, and you will also need to do some analysis of what the cost is to have this capability in place, but without the application making use of it (because anything remotely useful _will_ get enabled in a distro kernel, so how badly does it hurt high-performance server apps if it's compiled in) David Lang 0x48426C7E.asc Description: application/pgp-keys
Re: [PATCH] virtio-scsi: Skip setting affinity on uninitialized vq
Il 11/04/2014 03:23, Fam Zheng ha scritto:
virtscsi_init calls virtscsi_remove_vqs on err, even before initializing
the vqs. The latter calls virtscsi_set_affinity, so let's check the
pointer there before setting affinity on it.
This fixes a panic when setting device's num_queues=2 on RHEL 6.5:
qemu-system-x86_64 ... \
-device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \
-drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \
-device scsi-hd,drive=drive-scsi-disk,...
[0.354734] scsi0 : Virtio SCSI HBA
[0.379504] BUG: unable to handle kernel NULL pointer dereference at
0020
[0.380141] IP: [] __virtscsi_set_affinity+0x4f/0x120
[0.380141] PGD 0
[0.380141] Oops: [#1] SMP
[0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5
[0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[0.380141] task: 88003c9f ti: 88003c9f8000 task.ti:
88003c9f8000
[0.380141] RIP: 0010:[] []
__virtscsi_set_affinity+0x4f/0x120
[0.380141] RSP: :88003c9f9c08 EFLAGS: 00010256
[0.380141] RAX: RBX: 88003c3a9d40 RCX: 1070
[0.380141] RDX: 0002 RSI: RDI:
[0.380141] RBP: 88003c9f9c28 R08: 000136c0 R09: 88003c801c00
[0.380141] R10: 81475229 R11: 0008 R12:
[0.380141] R13: 81cc7ca8 R14: 88003cac3d40 R15: 88003cac37a0
[0.380141] FS: () GS:88003e40()
knlGS:
[0.380141] CS: 0010 DS: ES: CR0: 8005003b
[0.380141] CR2: 0020 CR3: 01c0e000 CR4: 06f0
[0.380141] Stack:
[0.380141] 88003c3a9d40 88003cac3d80
88003cac3d40
[0.380141] 88003c9f9c48 814742e8 88003c26d000
88003c26d000
[0.380141] 88003c9f9c68 81474321 88003c26d000
88003c3a9d40
[0.380141] Call Trace:
[0.380141] [] virtscsi_set_affinity+0x28/0x40
[0.380141] [] virtscsi_remove_vqs+0x21/0x50
[0.380141] [] virtscsi_init+0x91/0x240
[0.380141] [] ? vp_get+0x50/0x70
[0.380141] [] virtscsi_probe+0xf4/0x280
[0.380141] [] virtio_dev_probe+0xe5/0x140
[0.380141] [] driver_probe_device+0x89/0x230
[0.380141] [] __driver_attach+0x9b/0xa0
[0.380141] [] ? driver_probe_device+0x230/0x230
[0.380141] [] ? driver_probe_device+0x230/0x230
[0.380141] [] bus_for_each_dev+0x8c/0xb0
[0.380141] [] driver_attach+0x19/0x20
[0.380141] [] bus_add_driver+0x198/0x220
[0.380141] [] driver_register+0x5f/0xf0
[0.380141] [] ? spi_transport_init+0x79/0x79
[0.380141] [] register_virtio_driver+0x1b/0x30
[0.380141] [] init+0x88/0xd6
[0.380141] [] ? scsi_init_procfs+0x5b/0x5b
[0.380141] [] do_one_initcall+0x7f/0x10a
[0.380141] [] kernel_init_freeable+0x14a/0x1de
[0.380141] [] ? kernel_init_freeable+0x1de/0x1de
[0.380141] [] ? rest_init+0x80/0x80
[0.380141] [] kernel_init+0x9/0xf0
[0.380141] [] ret_from_fork+0x7c/0xb0
[0.380141] [] ? rest_init+0x80/0x80
[0.380141] RIP [] __virtscsi_set_affinity+0x4f/0x120
[0.380141] RSP
[0.380141] CR2: 0020
[0.380141] ---[ end trace 8074b70c3d5e1d73 ]---
[0.475018] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
[0.475018]
[0.475068] Kernel Offset: 0x0 from 0x8100 (relocation range:
0x8000-0x9fff)
[0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
Signed-off-by: Fam Zheng
---
drivers/scsi/virtio_scsi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..3019267 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -750,8 +750,12 @@ static void __virtscsi_set_affinity(struct virtio_scsi
*vscsi, bool affinity)
vscsi->affinity_hint_set = true;
} else {
- for (i = 0; i < vscsi->num_queues; i++)
+ for (i = 0; i < vscsi->num_queues; i++) {
+ if (!vscsi->req_vqs[i].vq) {
+ continue;
+ }
virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
+ }
vscsi->affinity_hint_set = false;
}
You put the if inside the loop, but it's really all or nothing since the
failure point is find_vqs.
Not a problem though; the queues are few and this is not a hot path anyway.
Acked-by: Paolo Bonzini
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] softirq: punt to ksoftirqd if __do_softirq recently looped
On 04/11/2014 04:33 PM, David Miller wrote:
> From: Rik van Riel
> Date: Thu, 10 Apr 2014 11:57:06 -0400
>
>> @@ -330,7 +334,11 @@ void irq_enter(void)
>>
>> static inline void invoke_softirq(void)
>> {
>> -if (!force_irqthreads) {
>> +/*
>> + * If force_irqthreads is set, or if we looped in __do_softirq this
>> + * jiffie, punt to ksoftirqd to prevent userland starvation.
>> + */
>> +if (!force_irqthreads && this_cpu_read(softirq_looped) != jiffies) {
>
> If we do this, which I'm not convinced of yet, I think we should use two
> jiffies as the cutoff.
I am not fully convinced, either. This patch mostly just illustrates
the problem, and gives something that solves Jiri's immediate problem.
It is quite likely that there is a better way to solve the problem of:
1) softirq handling starving out userspace processing,
2) which could be solved by moving the userspace process elsewhere, and
3) shifting softirq processing to ksoftirqd
A working patch seems to be one of the better ways to start a
discussion, though.
If anybody has a nicer idea on how to solve the problem, I'd even be
willing to implement your idea, and give Jiri another patch to test :)
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 1/1] X86: Probe for PIC and set legacy_pic appropriately
On 04/11/2014 05:50 PM, K. Y. Srinivasan wrote:
>
> + /*
> + * Check to see if we have a PIC.
> + * Mask all except the cascade and read
> + * back the value we just wrote. If we don't
> + * have a PIC, we will read 0xff as opposed to the
> + * value we wrote.
> + */
> + outb(probe_val, PIC_MASTER_IMR);
> + probe_val = inb(PIC_MASTER_IMR);
> + if (probe_val == 0xff) {
> + printk(KERN_INFO "Using NULL legacy PIC\n");
> + legacy_pic = _legacy_pic;
> + raw_spin_unlock_irqrestore(_lock, flags);
> + return;
> + }
> +
> outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
> outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
>
Again, I would do at least the slave masking above the probe.
Also, I would compare to make sure we get the probe_val back and compare
with != instead of comparing with ==.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1 1/1] X86: Probe for PIC and set legacy_pic appropriately
Probe for the existance of legacy PIC, if one does not exist, use the
null_legacy_pic.
This patch implements the proposal put forth by H. Peter Anvin
.
In this version of the patch I have cleaned up the code based on comments from
Peter.
Signed-off-by: K. Y. Srinivasan
---
arch/x86/kernel/cpu/mshyperv.c |2 --
arch/x86/kernel/i8259.c| 17 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 47359f7..9ca9587 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -133,8 +133,6 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
lapic_timer_frequency);
- printk(KERN_INFO "HyperV: Using null_legacy_pic\n");
- legacy_pic = _legacy_pic;
}
#endif
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 2e977b5..89c7313 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -299,11 +299,28 @@ static void unmask_8259A(void)
static void init_8259A(int auto_eoi)
{
unsigned long flags;
+ unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
i8259A_auto_eoi = auto_eoi;
raw_spin_lock_irqsave(_lock, flags);
+ /*
+* Check to see if we have a PIC.
+* Mask all except the cascade and read
+* back the value we just wrote. If we don't
+* have a PIC, we will read 0xff as opposed to the
+* value we wrote.
+*/
+ outb(probe_val, PIC_MASTER_IMR);
+ probe_val = inb(PIC_MASTER_IMR);
+ if (probe_val == 0xff) {
+ printk(KERN_INFO "Using NULL legacy PIC\n");
+ legacy_pic = _legacy_pic;
+ raw_spin_unlock_irqrestore(_lock, flags);
+ return;
+ }
+
outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cryogenic: Enabling Power-Aware Applications on Linux
On 04/12/2014 12:05 AM, Pavel Machek wrote: > Hi! > Cryogenic is the result of my Master's Thesis, completed at the Technical University of Munich under the supervision of Christian Grothoff. You can find more information about Cryogenic at https://gnunet.org/cryogenic >>> >>> Do you have any measurements how much power it actually saves? >> >> Yes, it depends on the device, but we have demonstrated power >> savings for two different types of devices using two different >> measurement setups performed by two independent groups. Some >> of the measurements are available on the website, the second >> set should become available "soon" (but we can already say that >> for the scenario we measured, the savings are in the same range >> as before). > > The video I seen AFAICT the savings are in <10% range? For the scenario we scripted, yes. But note that we only allowed 50% of the packets transmitted to be delayed (a bit). If you were to increase the allowed delay or allowed a larger fraction of packets to be delayed, you should see larger savings. > I seen demo on UDP packets... delayed TCP socket write is probably > easy, but would API allow delayed TCP connect? Yes. > Hmm, but the API needs redoing, anyway, fcntl()? Depends --- while I like the idea, I did not hear enough to be certain that having this feature embedded in such a non-modular way was already the consensus (and I do not see a reasonable way to change the API this way while maintaining the modularity of the current code). 0x48426C7E.asc Description: application/pgp-keys
Re: [PATCH 3.14 00/23] 3.14.1-stable review
On 04/11/2014 10:11 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.1 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Apr 13 16:11:46 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.1-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test systems. No dmesg regressions. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.13 00/65] 3.13.10-stable review
On 04/11/2014 10:10 AM, Greg Kroah-Hartman wrote: NOTE This is probably going to be the last 3.13.y kernel release. There _might_ be one more after this, but given my travel schedule for the next few weeks, don't count on it. Please move to the 3.14 kernel tree as soon as possible. This is the start of the stable review cycle for the 3.13.10 release. There are 65 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Apr 13 16:09:42 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.13.10-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test systems. No dmesg regressions. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/41] 3.10.37-stable review
On 04/11/2014 10:09 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.37 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Apr 13 16:09:00 UTC 2014. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.37-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test systems. No dmesg regressions. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fwserial: (unexhaustive) coding style review
From: Dominique van den Broeck fwserial: (unexhaustive) coding style review linux-next commit 88a8e0969581869c742a9957ddcfe43063dff687 Style-only modifications to make checkpatch.pl --file --strict a bit happier. I fixed only what was trivial, such as parenthesis alignments (one of them, at fwserial.c:1349, couldn't be easily replaced by something better, though). However, I did not comment by myself issues regarding spinlocks or memory barriers. This is my very first patch. Please be indulgent and forgive my eventual mistakes. I did that to start contributing to linux kernel, but also as task #10 of the Eudyptula Challenge ( http://eudyptula-challenge.org/ ). Signed-off-by: Dominique van den Broeck --- diff -upr a/drivers/staging/fwserial/dma_fifo.c b/drivers/staging/fwserial/dma_fifo.c --- a/drivers/staging/fwserial/dma_fifo.c 2014-04-11 20:48:20.813667706 +0200 +++ b/drivers/staging/fwserial/dma_fifo.c 2014-04-11 20:47:49.700058306 +0200 @@ -12,10 +12,6 @@ * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software Foundation, - * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include @@ -169,9 +165,9 @@ int dma_fifo_in(struct dma_fifo *fifo, c memcpy(fifo->data, src + l, n - l); if (FAIL(fifo, addr_check(fifo->done, fifo->in, fifo->in + n) || - fifo->avail < n, - "fifo corrupt: in:%u out:%u done:%u n:%d avail:%d", - fifo->in, fifo->out, fifo->done, n, fifo->avail)) +fifo->avail < n, +"fifo corrupt: in:%u out:%u done:%u n:%d avail:%d", +fifo->in, fifo->out, fifo->done, n, fifo->avail)) return -ENXIO; fifo->in += n; @@ -236,12 +232,12 @@ int dma_fifo_out_pend(struct dma_fifo *f ++fifo->open; if (FAIL(fifo, fifo->open > fifo->open_limit, - "past open limit:%d (limit:%d)", - fifo->open, fifo->open_limit)) +"past open limit:%d (limit:%d)", +fifo->open, fifo->open_limit)) return -ENXIO; if (FAIL(fifo, fifo->out & (fifo->align - 1), - "fifo out unaligned:%u (align:%u)", - fifo->out, fifo->align)) +"fifo out unaligned:%u (align:%u)", +fifo->out, fifo->align)) return -ENXIO; return len - n; @@ -264,8 +260,8 @@ int dma_fifo_out_complete(struct dma_fif return -EINVAL; if (FAIL(fifo, list_empty(>pending) != (fifo->open == 0), - "pending list disagrees with open count:%d", - fifo->open)) +"pending list disagrees with open count:%d", +fifo->open)) return -ENXIO; tmp = complete->data; @@ -282,10 +278,10 @@ int dma_fifo_out_complete(struct dma_fif } if (FAIL(fifo, pending->out != fifo->done || - addr_check(fifo->in, fifo->done, pending->next), - "in:%u out:%u done:%u saved:%u next:%u", - fifo->in, fifo->out, fifo->done, pending->out, - pending->next)) +addr_check(fifo->in, fifo->done, pending->next), +"in:%u out:%u done:%u saved:%u next:%u", +fifo->in, fifo->out, fifo->done, pending->out, +pending->next)) return -ENXIO; list_del_init(>link); @@ -300,7 +296,7 @@ int dma_fifo_out_complete(struct dma_fif if (FAIL(fifo, fifo->open < 0, "open dma:%d < 0", fifo->open)) return -ENXIO; if (FAIL(fifo, fifo->avail > fifo->size, "fifo avail:%d > size:%d", - fifo->avail, fifo->size)) +fifo->avail, fifo->size)) return -ENXIO; return 0; diff -upr a/drivers/staging/fwserial/dma_fifo.h b/drivers/staging/fwserial/dma_fifo.h --- a/drivers/staging/fwserial/dma_fifo.h 2014-04-11 20:48:20.813667706 +0200 +++ b/drivers/staging/fwserial/dma_fifo.h 2014-04-11 20:47:49.700058306 +0200 @@ -12,10 +12,6 @@ * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software Foundation, - * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #ifndef _DMA_FIFO_H_ @@ -85,15 +81,15 @@ static
[GIT PULL REQUEST] md for 3.15
Not much happening in md/raid at the moment. Just a few bug fixes (one for -stable) and a couple of performance tweaks. NeilBrown The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: git://neil.brown.name/md/ tags/md/3.15 for you to fetch changes up to e240c1839d11152b0355442f8ac6d2d2d921be36: raid5: get_active_stripe avoids device_lock (2014-04-09 14:42:42 +1000) Just a few md patches for the 3.15 merge window. NeilBrown (3): md/bitmap: don't abuse i_writecount for bitmap files. md/raid1: r1buf_pool_alloc: free allocate pages when subsequent allocation fails. md: avoid oops on unload if some process is in poll or select. Shaohua Li (2): raid5: make_request does less prepare wait raid5: get_active_stripe avoids device_lock drivers/md/bitmap.c | 1 - drivers/md/md.c | 65 ++--- drivers/md/md.h | 1 - drivers/md/raid1.c | 17 ++ drivers/md/raid5.c | 28 +-- 5 files changed, 61 insertions(+), 51 deletions(-) signature.asc Description: PGP signature
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
On Fri, Apr 11, 2014 at 3:46 PM, Serge E. Hallyn wrote: > Quoting Andy Lutomirski (l...@amacapital.net): >> On Fri, Apr 11, 2014 at 3:29 PM, Serge E. Hallyn wrote: >> > Quoting Andy Lutomirski (l...@amacapital.net): >> >> On Fri, Apr 11, 2014 at 2:52 PM, Serge E. Hallyn wrote: >> >> > Quoting Andy Lutomirski (l...@amacapital.net): >> >> >> On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn >> >> >> wrote: >> >> >> > Quoting Andy Lutomirski (l...@amacapital.net): >> >> >> >> I'm starting to think that we need to extend dumpable to something >> >> >> >> much more general like a list of struct creds that someone needs to >> >> >> >> be >> >> >> >> able to ptrace, *in addition to current creds* in order to access >> >> >> >> sensitive /proc files, coredumps, etc. If you get started as >> >> >> >> setuid, >> >> >> > >> >> >> > Hm, yeah, this sort of makes sense. >> >> >> > >> >> >> >> then you start with two struct creds in the list (or maybe just your >> >> >> >> euid and uid). If you get started !setuid, then your initial creds >> >> >> >> are in the list. It's possible that few or no things will need to >> >> >> >> change that list after execve. >> >> >> >> >> >> >> >> If all of the entries and current->cred are in the same user_ns, >> >> >> >> then >> >> >> >> we can dump as userns root. If they're in different usernses, then >> >> >> >> we >> >> >> >> dump as global root or maybe the common ancestor root. >> >> >> >> setuid(getuid()) and other such nastiness may have to empty the >> >> >> >> list, >> >> >> >> or maybe we can just use a prctl for that. >> >> >> > >> >> >> > A few questions, >> >> >> > >> >> >> > 1. is there any other action which would trigger adding a new cred to >> >> >> > the ist? >> >> >> >> >> >> I don't think so. Anyone who can ptrace you from the start can >> >> >> corrupt you such that you leak rights even if some future action >> >> >> prevents new ptracers from attaching. >> >> >> >> >> >> OTOH, it might be nice for something like an HTTPS server to be able >> >> >> to fork and shove its private key into the child, while preventing >> >> >> anyone from ptracing the child. But doing this securely without help >> >> >> from someone with a different uid might be impossible anyway. >> >> >> >> >> >> > >> >> >> > 2. would execve clear (and re-init) the list of creds? >> >> >> >> >> >> Probably. Thoughts? >> >> > >> >> > Yeah it seems to me it should be re-initialized, with a cred added >> >> > to the list for every open fd. >> >> >> >> What do you mean "every fd"? >> >> >> >> It seems odd to me that execve of anything that isn't setuid would add >> >> anything to the list -- attackers can always ptrace before the execve >> >> happens. >> > >> > Maybe you're right. Maybe I shouldn't reason about this on a friday >> > afternoon. >> > >> > My *thought* was setuid-root program opens /etc/shadow, then execs a >> > regular program keeping that open. Attaching to that fails now though, >> > presumably due to dumpable. >> > >> >> Why would it fail? > > I had expected it to succeed when I tried it, but it did in fact fail. > >> Isn't dumpable cleared on execve of a non-setuid >> program? Maybe I need to look this stuff up again. > > I guess this particular case was handled by setup_new_exec: > > if (uid_eq(current_euid(), current_uid()) && gid_eq(current_egid(), > current_gid())) > set_dumpable(current->mm, SUID_DUMP_USER); > else > set_dumpable(current->mm, suid_dumpable); > > since my euid was 0 and uid 1000, when I did the exec. > Then we need to keep this working. I guess we can just keep the dumpable bit around. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support
On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman wrote: > > Pins may be muxed to alternate function instead of gpio by firmware. > This driver does not touch the pin muxing and expect firmare > to set pin muxing and pullup/down properties properly. > > Signed-off-by: Mathias Nyman > --- > drivers/pinctrl/Kconfig| 12 + > drivers/pinctrl/Makefile |1 + > drivers/pinctrl/pinctrl-baytrail.c | 543 > I know it's been ten months since you posted this driver, but I have a question. If this driver does not touch the pin muxing, and it doesn't even call pinctrl_register(), then why is it in drivers/pinctrl? It's not a pinctrl driver. Why isn't this a regular GPIO drivers in drivers/gpio? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/base/node.c: export physical address range of given node (Re: NUMA node information for pages)
On 04/11/2014 03:13 PM, David Rientjes wrote: > What additional information, in your opinion, can we export to assist > userspace in making this determination that $address is on $nid? In the case of overlapping nodes, the only place we actually have *all* of the information is in the 'struct page' itself. Ulrich's original patch obviously _works_, and especially if it's an interface only for debugging purposes, it seems silly to spend virtually any time optimizing it. Keeping it close to pagemap's implementation lessens the likelihood that we'll screw things up. I assume that the original problem was trying to figure out what NUMA affinity a given range of pages mapped in to a _process_ have, and that /proc/$pid/numamaps is too coarse. Is that right, Ulrich? If you want to go the route of calculating and exporting the physical ranges that nodes uniquely own, you've *GOT* to handle the overlaps. Naoya had the right idea. His idea seemed to get shot down with the misunderstanding that node pfn ranges never overlap. The only other question is how many of these kpage* things we're going to put in here until we've exported the entire contents of 'struct page' 5 times over. :) We could add some tracepoints to the pagemap to dump lots of information in to a trace buffer that could be later read back. If you want detailed information (NUMA for instance), you turn the tracepoints and read pagemap for the range you care about. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Tomasz,
On Fri, Apr 11, 2014 at 7:56 PM, Tomasz Figa wrote:
> Hi,
>
>
> On 11.04.2014 11:41, Bartlomiej Zolnierkiewicz wrote:
>>
>>
>> Hi,
>>
>> On Friday, April 11, 2014 11:00:40 AM Chanwoo Choi wrote:
>>>
>>> This patch control special clock for ADC in Exynos series's FSYS block.
>>
>>
>> s/control/controls/
>>
>>> If special clock of ADC is registerd on clock list of common clk
>>> framework,
>>> Exynos ADC drvier have to control this clock.
>>
>>
>> s/drvier/driver/
>>
>>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>>> - 'adc' clock: bus clock for ADC
>>>
>>> Exynos3250 has additional 'sclk_tsadc' clock as following:
>>> - 'sclk_tsadc' clock: special clock for ADC which provide clock to
>>> internal ADC
>>>
>>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc'
>>> clock
>>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
>>> 'sclk_tsadc'
>>> clock in FSYS_BLK.
>>>
>>> Cc: Jonathan Cameron
>>> Cc: Kukjin Kim
>>> Cc: Naveen Krishna Chatradhi
>>> Cc: linux-...@vger.kernel.org
>>> Signed-off-by: Chanwoo Choi
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/iio/adc/exynos_adc.c | 13 +
>>> 1 file changed, 13 insertions(+)
>
>
> This change alters DT bindings for Exynos ADC, so documentation must be
> modified appropriately.
OK, I'll add DT modification patch on next posting.
>
>
>>>
>>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>>> index d25b262..4cd1975 100644
>>> --- a/drivers/iio/adc/exynos_adc.c
>>> +++ b/drivers/iio/adc/exynos_adc.c
>>> @@ -88,6 +88,7 @@ struct exynos_adc {
>>> void __iomem*regs;
>>> void __iomem*enable_reg;
>>> struct clk *clk;
>>> + struct clk *sclk;
>>> unsigned intirq;
>>> struct regulator*vdd;
>>>
>>> @@ -308,6 +309,13 @@ static int exynos_adc_probe(struct platform_device
>>> *pdev)
>>> goto err_irq;
>>> }
>>>
>>> + info->sclk = devm_clk_get(>dev, "sclk_tsadc");
>>> + if (IS_ERR(info->sclk)) {
>>> + dev_warn(>dev, "failed getting sclk clock, err =
>>> %ld\n",
>>> +
>>> PTR_ERR(info->sclk));
>>> + info->sclk = NULL;
>>> + }
>>> +
>
>
> Is there any reason why we should have a warning on SoCs which don't have
> this clock? I think this clock should be acquired only for affected SoCs.
You are right.
As Sylwester comment on previous reply, I'll consider to use new compatible name
to handle clock in only proper SoC according to compatible name.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL for v3.15-rc1] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus For a series of bug fix patches for v3.15-rc1. Most are just driver fixes. There are some changes at remote controller core level, fixing some definitions on a new API added for Kernel v3.15. It also adds the missing include at include/uapi/linux/v4l2-common.h, to allow its compilation on userspace, as pointed by you. Thanks, Mauro The following changes since commit 463b21fb27509061b3e97fb4fa69f26d089ddaf4: Merge branch 'topic/exynos' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2014-04-05 13:10:00 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to 32654fba2fdb417390efb1af29f1b5693bc91397: [media] gpsca: remove the risk of a division by zero (2014-04-08 11:01:12 -0300) Antti Palosaari (5): [media] msi001: fix possible integer overflow [media] msi3101: remove unused variable assignment [media] msi3101: check I/O return values on stop streaming [media] xc2028: add missing break to switch [media] rtl28xxu: remove duplicate ID 0458:707f Genius TVGo DVB-T03 Archit Taneja (9): [media] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs [media] v4l: ti-vpe: Use video_device_release_empty [media] v4l: ti-vpe: Allow usage of smaller images [media] v4l: ti-vpe: report correct capabilities in querycap [media] v4l: ti-vpe: Use correct bus_info name for the device in querycap [media] v4l: ti-vpe: Fix initial configuration queue data [media] v4l: ti-vpe: zero out reserved fields in try_fmt [media] v4l: ti-vpe: Set correct field parameter for output and capture buffers [media] v4l: ti-vpe: retain v4l2_buffer flags for captured buffers Benjamin Larsson (1): [media] r820t: fix size and init values David Härdeman (3): [media] rc-core: do not change 32bit NEC scancode format for now [media] rc-core: split dev->s_filter [media] rc-core: remove generic scancode filter Malcolm Priestley (1): [media] m88rs2000: fix sparse static warnings Mauro Carvalho Chehab (3): [media] v4l2-common: fix warning when used on userpace [media] stk1160: warrant a NUL terminated string [media] gpsca: remove the risk of a division by zero Paul Bolle (1): [media] drx-j: use customise option correctly Shuah Khan (1): [media] lgdt3305: include sleep functionality in lgdt3304_ops drivers/media/dvb-frontends/drx39xyj/Kconfig | 2 +- drivers/media/dvb-frontends/lgdt3305.c | 1 + drivers/media/dvb-frontends/m88rs2000.c | 8 +-- drivers/media/platform/ti-vpe/vpe.c | 45 + drivers/media/rc/img-ir/img-ir-hw.c | 15 - drivers/media/rc/img-ir/img-ir-nec.c | 27 drivers/media/rc/ir-nec-decoder.c| 5 +- drivers/media/rc/keymaps/rc-tivo.c | 86 drivers/media/rc/rc-main.c | 98 ++-- drivers/media/tuners/r820t.c | 3 +- drivers/media/tuners/tuner-xc2028.c | 1 + drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 - drivers/media/usb/gspca/jpeg.h | 4 +- drivers/media/usb/stk1160/stk1160-ac97.c | 2 +- drivers/staging/media/msi3101/msi001.c | 2 +- drivers/staging/media/msi3101/sdr-msi3101.c | 15 +++-- include/media/rc-core.h | 8 ++- include/uapi/linux/v4l2-common.h | 2 + 18 files changed, 200 insertions(+), 126 deletions(-) -- Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] X86: Probe for PIC and set legacy_pic appropriately
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Friday, April 11, 2014 3:36 PM
> To: KY Srinivasan; x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> jbeul...@suse.com; b...@alien8.de
> Cc: Thomas Gleixner
> Subject: Re: [PATCH 1/1] X86: Probe for PIC and set legacy_pic appropriately
>
> On 04/11/2014 04:02 PM, K. Y. Srinivasan wrote:
> >
> > diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c index
> > 2e977b5..0a57a19 100644
> > --- a/arch/x86/kernel/i8259.c
> > +++ b/arch/x86/kernel/i8259.c
> > @@ -299,11 +299,22 @@ static void unmask_8259A(void) static void
> > init_8259A(int auto_eoi) {
> > unsigned long flags;
> > + unsigned char probe_val = 0xfb;
> >
> > i8259A_auto_eoi = auto_eoi;
> >
> > raw_spin_lock_irqsave(_lock, flags);
> >
> > + /* Check to see if we have a PIC */
> > + outb(probe_val, PIC_MASTER_IMR);
> > + probe_val = inb(PIC_MASTER_IMR);
> > + if (probe_val == 0xff) {
> > + printk(KERN_INFO "Using NULL legacy PIC\n");
> > + legacy_pic = _legacy_pic;
> > + raw_spin_unlock_irqrestore(_lock, flags);
> > + return;
> > + }
> > +
> > outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
> > outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
> >
>
> I think it is important to document what this actually means here. 0xfb is
> "mask all except for the cascade."
>
> Arguably, we should do this after masking the slave PIC.
>
> On a whole other subject... the whole __byte() logic is a just plain horrific
> piece of crap. Clearly whomever wrote it had never heard of a union.
>
> I'm still horrifically confused, though, why we mask IRQ 2 (the cascade
> interrupt) in i8259.c, but we explicitly do *not* mask IRQ 2 in boot/pm.c (nor
> in the assembly code on which boot/pm.c was based.) In fact, it looks like we
> never unmask it. I'm guessing that the masking status of the cascade input
> simply doesn't matter.
>
> At the very least, though, we shouldn't have 0xfb as a magic number, but use
> ~(1U << PIC_CASCADE_IR).
I will get rid of this magic number as you have suggested.
K. Y
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Sylwester, On Fri, Apr 11, 2014 at 7:05 PM, Sylwester Nawrocki wrote: > Hi Chanwoo, > > On 11/04/14 04:00, Chanwoo Choi wrote: >> This patch control special clock for ADC in Exynos series's FSYS block. >> If special clock of ADC is registerd on clock list of common clk framework, >> Exynos ADC drvier have to control this clock. >> >> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following: >> - 'adc' clock: bus clock for ADC >> >> Exynos3250 has additional 'sclk_tsadc' clock as following: >> - 'sclk_tsadc' clock: special clock for ADC which provide clock to internal >> ADC >> >> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock >> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included >> 'sclk_tsadc' >> clock in FSYS_BLK. > > I think a new compatible should be added for the ADC device for Exynos3250 > and the required clocks should be handled properly, based on compatible > value. This could be handled, e.g. through some flags in driver's data > selected based on the compatible property value. OK, I'll consider new patch using new compatible string according to your comment. > > And the new clocks should be documented in Documentation/devicetree/bindings > /arm/samsung/exynos-adc.txt. OK, I'll modify it. Thanks, Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
Hi Bartlomiej,
On Fri, Apr 11, 2014 at 6:41 PM, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> On Friday, April 11, 2014 11:00:40 AM Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>
> s/control/controls/
I'll fix it.
>
>> If special clock of ADC is registerd on clock list of common clk framework,
>> Exynos ADC drvier have to control this clock.
>
> s/drvier/driver/
I'll fix it.
>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_tsadc' clock as following:
>> - 'sclk_tsadc' clock: special clock for ADC which provide clock to internal
>> ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_tsadc' clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included
>> 'sclk_tsadc'
>> clock in FSYS_BLK.
>>
>> Cc: Jonathan Cameron
>> Cc: Kukjin Kim
>> Cc: Naveen Krishna Chatradhi
>> Cc: linux-...@vger.kernel.org
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/iio/adc/exynos_adc.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index d25b262..4cd1975 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -88,6 +88,7 @@ struct exynos_adc {
>> void __iomem*regs;
>> void __iomem*enable_reg;
>> struct clk *clk;
>> + struct clk *sclk;
>> unsigned intirq;
>> struct regulator*vdd;
>>
>> @@ -308,6 +309,13 @@ static int exynos_adc_probe(struct platform_device
>> *pdev)
>> goto err_irq;
>> }
>>
>> + info->sclk = devm_clk_get(>dev, "sclk_tsadc");
>> + if (IS_ERR(info->sclk)) {
>> + dev_warn(>dev, "failed getting sclk clock, err = %ld\n",
>> + PTR_ERR(info->sclk));
>> + info->sclk = NULL;
>> + }
>> +
>> info->vdd = devm_regulator_get(>dev, "vdd");
>> if (IS_ERR(info->vdd)) {
>> dev_err(>dev, "failed getting regulator, err = %ld\n",
>> @@ -341,6 +349,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
>> goto err_iio_dev;
>>
>> clk_prepare_enable(info->clk);
>> + clk_prepare_enable(info->sclk);
>>
>> exynos_adc_hw_init(info);
>>
>> @@ -357,6 +366,7 @@ err_of_populate:
>> exynos_adc_remove_devices);
>> regulator_disable(info->vdd);
>> clk_disable_unprepare(info->clk);
>> + clk_disable_unprepare(info->sclk);
>
> Please disable clocks in the reverse of order in which they were enabled.
Is it necessary? I don't think that.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
Quoting Andy Lutomirski (l...@amacapital.net): > On Fri, Apr 11, 2014 at 3:29 PM, Serge E. Hallyn wrote: > > Quoting Andy Lutomirski (l...@amacapital.net): > >> On Fri, Apr 11, 2014 at 2:52 PM, Serge E. Hallyn wrote: > >> > Quoting Andy Lutomirski (l...@amacapital.net): > >> >> On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn > >> >> wrote: > >> >> > Quoting Andy Lutomirski (l...@amacapital.net): > >> >> >> I'm starting to think that we need to extend dumpable to something > >> >> >> much more general like a list of struct creds that someone needs to > >> >> >> be > >> >> >> able to ptrace, *in addition to current creds* in order to access > >> >> >> sensitive /proc files, coredumps, etc. If you get started as setuid, > >> >> > > >> >> > Hm, yeah, this sort of makes sense. > >> >> > > >> >> >> then you start with two struct creds in the list (or maybe just your > >> >> >> euid and uid). If you get started !setuid, then your initial creds > >> >> >> are in the list. It's possible that few or no things will need to > >> >> >> change that list after execve. > >> >> >> > >> >> >> If all of the entries and current->cred are in the same user_ns, then > >> >> >> we can dump as userns root. If they're in different usernses, then > >> >> >> we > >> >> >> dump as global root or maybe the common ancestor root. > >> >> >> setuid(getuid()) and other such nastiness may have to empty the list, > >> >> >> or maybe we can just use a prctl for that. > >> >> > > >> >> > A few questions, > >> >> > > >> >> > 1. is there any other action which would trigger adding a new cred to > >> >> > the ist? > >> >> > >> >> I don't think so. Anyone who can ptrace you from the start can > >> >> corrupt you such that you leak rights even if some future action > >> >> prevents new ptracers from attaching. > >> >> > >> >> OTOH, it might be nice for something like an HTTPS server to be able > >> >> to fork and shove its private key into the child, while preventing > >> >> anyone from ptracing the child. But doing this securely without help > >> >> from someone with a different uid might be impossible anyway. > >> >> > >> >> > > >> >> > 2. would execve clear (and re-init) the list of creds? > >> >> > >> >> Probably. Thoughts? > >> > > >> > Yeah it seems to me it should be re-initialized, with a cred added > >> > to the list for every open fd. > >> > >> What do you mean "every fd"? > >> > >> It seems odd to me that execve of anything that isn't setuid would add > >> anything to the list -- attackers can always ptrace before the execve > >> happens. > > > > Maybe you're right. Maybe I shouldn't reason about this on a friday > > afternoon. > > > > My *thought* was setuid-root program opens /etc/shadow, then execs a > > regular program keeping that open. Attaching to that fails now though, > > presumably due to dumpable. > > > > Why would it fail? I had expected it to succeed when I tried it, but it did in fact fail. > Isn't dumpable cleared on execve of a non-setuid > program? Maybe I need to look this stuff up again. I guess this particular case was handled by setup_new_exec: if (uid_eq(current_euid(), current_uid()) && gid_eq(current_egid(), current_gid())) set_dumpable(current->mm, SUID_DUMP_USER); else set_dumpable(current->mm, suid_dumpable); since my euid was 0 and uid 1000, when I did the exec. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/27] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
Hi Arnd, On Fri, Apr 11, 2014 at 5:41 PM, Arnd Bergmann wrote: > On Friday 11 April 2014 11:03:18 Chanwoo Choi wrote: >> On 04/11/2014 10:48 AM, Olof Johansson wrote: >> > On Thu, Apr 10, 2014 at 06:37:14PM +0900, Chanwoo Choi wrote: >> >> This patch add memory mapping for PMU (Power Management Unit) which is >> >> used >> >> for power control of Exynos3250. >> >> >> >> Signed-off-by: Chanwoo Choi >> >> Signed-off-by: Kyungmin Park >> > >> > Signed-off-by is in the wrong order, if Kyungmin wrote the patch and you're >> > just posting it... >> >> >> No, I implemented this patch and posted it. > > What did Kyungmin do then? If you submitted the patch to him, and he > sent it back to you, you should be listed twice, although you could > just as easily leave him out. > Sorry, It has happen a confusion due to my mistake. As I reply on other patch as Olof comment, I'll use 'Acked-by' instead of 'Signed-off' for Kyungmin Park. - [PATCH 12/27] ARM: dts: exynos3250: Add default interrupt-parent connected with GIC Thanks, Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] X86: Probe for PIC and set legacy_pic appropriately
On 04/11/2014 04:02 PM, K. Y. Srinivasan wrote:
>
> diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
> index 2e977b5..0a57a19 100644
> --- a/arch/x86/kernel/i8259.c
> +++ b/arch/x86/kernel/i8259.c
> @@ -299,11 +299,22 @@ static void unmask_8259A(void)
> static void init_8259A(int auto_eoi)
> {
> unsigned long flags;
> + unsigned char probe_val = 0xfb;
>
> i8259A_auto_eoi = auto_eoi;
>
> raw_spin_lock_irqsave(_lock, flags);
>
> + /* Check to see if we have a PIC */
> + outb(probe_val, PIC_MASTER_IMR);
> + probe_val = inb(PIC_MASTER_IMR);
> + if (probe_val == 0xff) {
> + printk(KERN_INFO "Using NULL legacy PIC\n");
> + legacy_pic = _legacy_pic;
> + raw_spin_unlock_irqrestore(_lock, flags);
> + return;
> + }
> +
> outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
> outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
>
I think it is important to document what this actually means here. 0xfb
is "mask all except for the cascade."
Arguably, we should do this after masking the slave PIC.
On a whole other subject... the whole __byte() logic is a just plain
horrific piece of crap. Clearly whomever wrote it had never heard of a
union.
I'm still horrifically confused, though, why we mask IRQ 2 (the cascade
interrupt) in i8259.c, but we explicitly do *not* mask IRQ 2 in
boot/pm.c (nor in the assembly code on which boot/pm.c was based.) In
fact, it looks like we never unmask it. I'm guessing that the masking
status of the cascade input simply doesn't matter.
At the very least, though, we shouldn't have 0xfb as a magic number, but
use ~(1U << PIC_CASCADE_IR).
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
On Fri, Apr 11, 2014 at 3:29 PM, Serge E. Hallyn wrote: > Quoting Andy Lutomirski (l...@amacapital.net): >> On Fri, Apr 11, 2014 at 2:52 PM, Serge E. Hallyn wrote: >> > Quoting Andy Lutomirski (l...@amacapital.net): >> >> On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn wrote: >> >> > Quoting Andy Lutomirski (l...@amacapital.net): >> >> >> I'm starting to think that we need to extend dumpable to something >> >> >> much more general like a list of struct creds that someone needs to be >> >> >> able to ptrace, *in addition to current creds* in order to access >> >> >> sensitive /proc files, coredumps, etc. If you get started as setuid, >> >> > >> >> > Hm, yeah, this sort of makes sense. >> >> > >> >> >> then you start with two struct creds in the list (or maybe just your >> >> >> euid and uid). If you get started !setuid, then your initial creds >> >> >> are in the list. It's possible that few or no things will need to >> >> >> change that list after execve. >> >> >> >> >> >> If all of the entries and current->cred are in the same user_ns, then >> >> >> we can dump as userns root. If they're in different usernses, then we >> >> >> dump as global root or maybe the common ancestor root. >> >> >> setuid(getuid()) and other such nastiness may have to empty the list, >> >> >> or maybe we can just use a prctl for that. >> >> > >> >> > A few questions, >> >> > >> >> > 1. is there any other action which would trigger adding a new cred to >> >> > the ist? >> >> >> >> I don't think so. Anyone who can ptrace you from the start can >> >> corrupt you such that you leak rights even if some future action >> >> prevents new ptracers from attaching. >> >> >> >> OTOH, it might be nice for something like an HTTPS server to be able >> >> to fork and shove its private key into the child, while preventing >> >> anyone from ptracing the child. But doing this securely without help >> >> from someone with a different uid might be impossible anyway. >> >> >> >> > >> >> > 2. would execve clear (and re-init) the list of creds? >> >> >> >> Probably. Thoughts? >> > >> > Yeah it seems to me it should be re-initialized, with a cred added >> > to the list for every open fd. >> >> What do you mean "every fd"? >> >> It seems odd to me that execve of anything that isn't setuid would add >> anything to the list -- attackers can always ptrace before the execve >> happens. > > Maybe you're right. Maybe I shouldn't reason about this on a friday > afternoon. > > My *thought* was setuid-root program opens /etc/shadow, then execs a > regular program keeping that open. Attaching to that fails now though, > presumably due to dumpable. > Why would it fail? Isn't dumpable cleared on execve of a non-setuid program? Maybe I need to look this stuff up again. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] arch/arm/mach-ks8695/board-og.c: __initdata fix
Place __initdata before equal signs.
Cc: linux-arm-ker...@lists.infradead.org
Cc: Andrew Morton
---
arch/arm/mach-ks8695/board-og.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
index f265816..2627d82 100644
--- a/arch/arm/mach-ks8695/board-og.c
+++ b/arch/arm/mach-ks8695/board-og.c
@@ -30,7 +30,7 @@ static int og_pci_map_irq(const struct pci_dev *dev, u8 slot,
u8 pin)
return KS8695_IRQ_EXTERN0;
}
-static struct ks8695_pci_cfg __initdata og_pci = {
+static struct ks8695_pci_cfg og_pci __initdata = {
.mode = KS8695_MODE_PCI,
.map_irq= og_pci_map_irq,
};
@@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
#defineS8250_VIRT 0xf400
#defineS8250_SIZE 0x0010
-static struct __initdata map_desc og_io_desc[] = {
+static struct map_desc og_io_desc[] __initdata = {
{
.virtual= S8250_VIRT,
.pfn= __phys_to_pfn(S8250_PHYS),
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/27] ARM: dts: exynos3250: Add default interrupt-parent connected with GIC
Hi Tomasz, On Fri, Apr 11, 2014 at 5:51 PM, Tomasz Figa wrote: > Hi Chanwoo, > > > On 11.04.2014 06:44, Chanwoo Choi wrote: >> >> Hi, >> >> On 04/11/2014 01:00 PM, Olof Johansson wrote: >>> >>> On Thu, Apr 10, 2014 at 07:06:02PM +0900, Chanwoo Choi wrote: This patch add interrupt-parent node to connected with GIC. All interrupt-related dt nodes need default interrupt-parent node. Signed-off-by: Chanwoo Choi Signed-off-by: Kyungmin Park >>> >>> >>> There's no point in splitting these off in separate patches; fold them >>> into one patch that introduces the SoC dtsi, please. >> >> >> OK, I will consolidate following two patches into one patch. >> >> [PATCH 11/27] ARM: dts: exynos3250: Add GIC dt node for Exynos3250 >> [PATCH 12/27] ARM: dts: exynos3250: Add default interrupt-parent connected >> with GIC >> > > I believe the intention was to squash all the patches related to > exynos3250.dtsi into a single patch called "ARM: dts: Add device tree > sources for Exynos3250". To retain authorship information, signed-off-by > tags should be merged from all those patches too. > As you comment, I will consolidate exynos3250.dtsi into only one patch on next posting(v2). Thanks, Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
Quoting Andy Lutomirski (l...@amacapital.net): > On Fri, Apr 11, 2014 at 2:52 PM, Serge E. Hallyn wrote: > > Quoting Andy Lutomirski (l...@amacapital.net): > >> On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn wrote: > >> > Quoting Andy Lutomirski (l...@amacapital.net): > >> >> I'm starting to think that we need to extend dumpable to something > >> >> much more general like a list of struct creds that someone needs to be > >> >> able to ptrace, *in addition to current creds* in order to access > >> >> sensitive /proc files, coredumps, etc. If you get started as setuid, > >> > > >> > Hm, yeah, this sort of makes sense. > >> > > >> >> then you start with two struct creds in the list (or maybe just your > >> >> euid and uid). If you get started !setuid, then your initial creds > >> >> are in the list. It's possible that few or no things will need to > >> >> change that list after execve. > >> >> > >> >> If all of the entries and current->cred are in the same user_ns, then > >> >> we can dump as userns root. If they're in different usernses, then we > >> >> dump as global root or maybe the common ancestor root. > >> >> setuid(getuid()) and other such nastiness may have to empty the list, > >> >> or maybe we can just use a prctl for that. > >> > > >> > A few questions, > >> > > >> > 1. is there any other action which would trigger adding a new cred to > >> > the ist? > >> > >> I don't think so. Anyone who can ptrace you from the start can > >> corrupt you such that you leak rights even if some future action > >> prevents new ptracers from attaching. > >> > >> OTOH, it might be nice for something like an HTTPS server to be able > >> to fork and shove its private key into the child, while preventing > >> anyone from ptracing the child. But doing this securely without help > >> from someone with a different uid might be impossible anyway. > >> > >> > > >> > 2. would execve clear (and re-init) the list of creds? > >> > >> Probably. Thoughts? > > > > Yeah it seems to me it should be re-initialized, with a cred added > > to the list for every open fd. > > What do you mean "every fd"? > > It seems odd to me that execve of anything that isn't setuid would add > anything to the list -- attackers can always ptrace before the execve > happens. Maybe you're right. Maybe I shouldn't reason about this on a friday afternoon. My *thought* was setuid-root program opens /etc/shadow, then execs a regular program keeping that open. Attaching to that fails now though, presumably due to dumpable. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: s3c2410: resume race fix
From: Olof Johansson Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson Signed-off-by: Doug Anderson --- drivers/i2c/busses/i2c-s3c2410.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index ae44910..bb3a996 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1276,10 +1276,10 @@ static int s3c24xx_i2c_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev); - i2c->suspended = 0; clk_prepare_enable(i2c->clk); s3c24xx_i2c_init(i2c); clk_disable_unprepare(i2c->clk); + i2c->suspended = 0; return 0; } -- 1.9.1.423.g4596e3a -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On 04/11/2014 03:15 PM, Andy Lutomirski wrote: > > I just looked up my hideous code. I was doing this to test the > now-deleted int 0xcc vsyscall stuff. I used modify_ldt because either > I didn't realize that __USER32_CS was usable or I didn't think it was > ABI. Or I was just being silly. > > But yes, breaking my hack would not matter. :) > Either way, it wouldn't break it. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On Fri, Apr 11, 2014 at 2:59 PM, H. Peter Anvin wrote: > On 04/11/2014 02:53 PM, Andy Lutomirski wrote: >> >> How big of a functionality problem is it? Apparently it doesn't break >> 16-bit code on wine. >> > > It breaks *some* 16-bit code. This is actually the reason that 32 bits > has the espfix workaround - it wasn't identified as an infoleak at the time. > >> Since the high bits of esp have been corrupted on x86_64 since the >> beginning, there's no regression issue here if an eventual fix writes >> less meaningful crap to those bits -- I see no real reason to try to put >> the correct values in there. > > It is a regression vs. the 32-bit kernel, and if we're going to support > 16-bit code we should arguably support 16-bit code correctly. > > This is actually how I stumbled onto this problem in the first place: it > broke a compiler test suite for gcc -m16 I was working on. The > workaround for *that* was to run in a VM instead. > I would have suggested rejecting modify_ldt() entirely, to reduce attack surface, except that some early versions of 32-bit NPTL glibc use modify_ldt() to exclusion of all other methods of establishing the thread pointer, so in order to stay compatible with those we would need to allow 32-bit segments via modify_ldt() still. >> >> I actually use modify_ldt for amusement: it's the only way I know of to >> issue real 32-bit syscalls from 64-bit userspace. Yes, this isn't >> really a legitimate use case. > > That's actually wrong on no less than two levels: > > 1. You can issue real 32-bit system calls from 64-bit user space simply >by invoking int $0x80; it works in 64-bit mode as well. > > 2. Even if you want to be in 32-bit mode you can simply call via >__USER32_CS, you don't need an LDT entry. I just looked up my hideous code. I was doing this to test the now-deleted int 0xcc vsyscall stuff. I used modify_ldt because either I didn't realize that __USER32_CS was usable or I didn't think it was ABI. Or I was just being silly. But yes, breaking my hack would not matter. :) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/base/node.c: export physical address range of given node (Re: NUMA node information for pages)
On Fri, 11 Apr 2014, Dave Hansen wrote: > > So? Who cares if there are non-addressable holes in part of the span? > > Ulrich, correct me if I'm wrong, but it seems you're looking for just a > > address-to-nodeid mapping (or pfn-to-nodeid mapping) and aren't actually > > expecting that there are no holes in a node for things like acpi or I/O or > > reserved memory. > ... > > I think trying to represent holes and handling different memory models and > > hotplug in special ways is complete overkill. > > This isn't just about memory hotplug or different memory models. There > are systems out there today, in production, that have layouts like this: > > |--Node0-| > |--Node1-| > > and this: > > |--Node0-| > |-Node1-| > What additional information, in your opinion, can we export to assist userspace in making this determination that $address is on $nid? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
On Fri, Apr 11, 2014 at 2:52 PM, Serge E. Hallyn wrote: > Quoting Andy Lutomirski (l...@amacapital.net): >> On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn wrote: >> > Quoting Andy Lutomirski (l...@amacapital.net): >> >> I'm starting to think that we need to extend dumpable to something >> >> much more general like a list of struct creds that someone needs to be >> >> able to ptrace, *in addition to current creds* in order to access >> >> sensitive /proc files, coredumps, etc. If you get started as setuid, >> > >> > Hm, yeah, this sort of makes sense. >> > >> >> then you start with two struct creds in the list (or maybe just your >> >> euid and uid). If you get started !setuid, then your initial creds >> >> are in the list. It's possible that few or no things will need to >> >> change that list after execve. >> >> >> >> If all of the entries and current->cred are in the same user_ns, then >> >> we can dump as userns root. If they're in different usernses, then we >> >> dump as global root or maybe the common ancestor root. >> >> setuid(getuid()) and other such nastiness may have to empty the list, >> >> or maybe we can just use a prctl for that. >> > >> > A few questions, >> > >> > 1. is there any other action which would trigger adding a new cred to >> > the ist? >> >> I don't think so. Anyone who can ptrace you from the start can >> corrupt you such that you leak rights even if some future action >> prevents new ptracers from attaching. >> >> OTOH, it might be nice for something like an HTTPS server to be able >> to fork and shove its private key into the child, while preventing >> anyone from ptracing the child. But doing this securely without help >> from someone with a different uid might be impossible anyway. >> >> > >> > 2. would execve clear (and re-init) the list of creds? >> >> Probably. Thoughts? > > Yeah it seems to me it should be re-initialized, with a cred added > to the list for every open fd. What do you mean "every fd"? It seems odd to me that execve of anything that isn't setuid would add anything to the list -- attackers can always ptrace before the execve happens. > >> We could have a way to ask execve not to reinit the list. Such a >> mechanism would have to require no_new_privs to prevent a >> straightforward attack on any setuid binary. > > If we don't add a cred for every open fd, then I think we need this. If > we do, then I'm not sure this makes sense. See above. I think I'm misunderstanding you. > >> We's also want PR_SET_DUMPABLE or a new prctl to be able reset the >> list to contain just current-.cred, I think. > > Yeah PR_SET_DUMPABLE should reset it, agreed. > > -serge --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: cdc-acm: fix double usb_autopm_put_interface() in acm_port_activate()
If acm_submit_read_urbs() fails in acm_port_activate(), error handling
code calls usb_autopm_put_interface() while it is already called
before acm_submit_read_urbs(). The patch reorganizes error handling code
to avoid double decrement of USB interface's PM-usage counter.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/usb/class/cdc-acm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff805ee..d5d2c922186a 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -518,13 +518,16 @@ static int acm_port_activate(struct tty_port *port,
struct tty_struct *tty)
if (usb_submit_urb(acm->ctrlurb, GFP_KERNEL)) {
dev_err(>control->dev,
"%s - usb_submit_urb(ctrl irq) failed\n", __func__);
+ usb_autopm_put_interface(acm->control);
goto error_submit_urb;
}
acm->ctrlout = ACM_CTRL_DTR | ACM_CTRL_RTS;
if (acm_set_control(acm, acm->ctrlout) < 0 &&
- (acm->ctrl_caps & USB_CDC_CAP_LINE))
+ (acm->ctrl_caps & USB_CDC_CAP_LINE)) {
+ usb_autopm_put_interface(acm->control);
goto error_set_control;
+ }
usb_autopm_put_interface(acm->control);
@@ -549,7 +552,6 @@ error_submit_read_urbs:
error_set_control:
usb_kill_urb(acm->ctrlurb);
error_submit_urb:
- usb_autopm_put_interface(acm->control);
error_get_interface:
disconnected:
mutex_unlock(>mutex);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] shm: add sealing API
On Fri, Apr 11, 2014 at 2:42 PM, David Herrmann wrote: > Hi > > On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski wrote: >> A quick grep of the kernel tree finds exactly zero code paths >> incrementing i_mmap_writable outside of mmap and fork. >> >> Or do you mean a different kind of write ref? What am I missing here? > > Sorry, I meant i_writecount. I bet this is missing from lots of places. For example, I can't find any write_access stuff in the rdma code. I suspect that the VM_DENYWRITE code is just generally racy. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] X86: Probe for PIC and set legacy_pic appropriately
Probe for the existance of legacy PIC, if one does not exist, use the
null_legacy_pic.
This patch implements the proposal put forth by H. Peter Anvin
.
Signed-off-by: K. Y. Srinivasan
---
arch/x86/kernel/cpu/mshyperv.c |2 --
arch/x86/kernel/i8259.c| 11 +++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 47359f7..9ca9587 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -133,8 +133,6 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
lapic_timer_frequency);
- printk(KERN_INFO "HyperV: Using null_legacy_pic\n");
- legacy_pic = _legacy_pic;
}
#endif
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 2e977b5..0a57a19 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -299,11 +299,22 @@ static void unmask_8259A(void)
static void init_8259A(int auto_eoi)
{
unsigned long flags;
+ unsigned char probe_val = 0xfb;
i8259A_auto_eoi = auto_eoi;
raw_spin_lock_irqsave(_lock, flags);
+ /* Check to see if we have a PIC */
+ outb(probe_val, PIC_MASTER_IMR);
+ probe_val = inb(PIC_MASTER_IMR);
+ if (probe_val == 0xff) {
+ printk(KERN_INFO "Using NULL legacy PIC\n");
+ legacy_pic = _legacy_pic;
+ raw_spin_unlock_irqrestore(_lock, flags);
+ return;
+ }
+
outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cryogenic: Enabling Power-Aware Applications on Linux
Hi! > >> Cryogenic is the result of my Master's Thesis, completed at the Technical > >> University > >> of Munich under the supervision of Christian Grothoff. You can find more > >> information > >> about Cryogenic at https://gnunet.org/cryogenic > > > > Do you have any measurements how much power it actually saves? > > Yes, it depends on the device, but we have demonstrated power > savings for two different types of devices using two different > measurement setups performed by two independent groups. Some > of the measurements are available on the website, the second > set should become available "soon" (but we can already say that > for the scenario we measured, the savings are in the same range > as before). The video I seen AFAICT the savings are in <10% range? > > "I'd like to download my mails from IMAP server in next 30 > > minutes. But... it would be better done when I'm on 3G network with > > good signal (0.01W transmit power used for 3 seconds) than on GPRS > > with poor signal (2W transmit power for 4 minutes)..." > > Well, that's not quite what the API would allow, especially as it > is obviously hard to predict that a different network will become > available. Actually... its a phone so it probably has GPS :-). But I'd guess that even simpler logic, "if UMTS was available in last hour, it is likely to be available within hour" would work ok. I seen demo on UDP packets... delayed TCP socket write is probably easy, but would API allow delayed TCP connect? Hmm, but the API needs redoing, anyway, fcntl()? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DRM security flaws and security levels.
On Fri, Apr 11, 2014 at 5:15 PM, Thomas Hellstrom wrote: > On 04/11/2014 10:31 PM, David Herrmann wrote: >> Hi >> >> On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom >> wrote: >>> as was discussed a while ago, there are some serious security flaws with >>> the current drm master model, that allows a >>> user that had previous access or current access to an X server terminal >>> to access the GPU memory of the active X server, without being >>> authenticated to the X server and thereby also access other user's >>> secret information >> 1a) and 1b) are moot if you disallow primary-node access but require >> clients to use render-nodes with dma-buf. There're no gem-names on >> render-nodes so no way to access other buffers (assuming the GPU does >> command-stream checking and/or VM). > > Disallowing primary node access will break older user-space drivers and > non-root > EGL clients. I'm not sure that's OK, even if the change is done from > user-space. > A simple gem fix would also do the trick. > >> >> 2) There is no DRM-generic data other than buffers that is global. So >> imho this is a driver-specific issue. >> >> So I cannot see why this is a DRM issue. The only leaks I see are >> legacy interfaces and driver-specific interfaces. The first can be >> disabled via chmod() for clients, and the second is something driver >> authors should fix. > > Yeah, but some driver authors can't or won't fix the drivers w r t this, > hence the security levels. fwiw, I do think we want security level reporting for drivers that don't have per-process pagetables (either the hw doesn't support, or simply just not implemented yet) to avoid giving a false sense of security with rendernodes. It might be useful to even be able to request a security level.. ie. some hw might be able to support process isolation of gpu buffers, but at a performance penalty.. Joe Gamer might be ok with the tradeoff in return for moar fps. Ideally you could request on a per process basis (via some sort of egl/glx extension) to firewall off, say, your online banking session. note, sencario 1a is, I think, only an issue for shared buffers (ie. ones that have an flink name).. so, ok, another process can see the video game you were playing. Ok, that is not quite true, since browsers use gpu accel (but maybe they want to decide to enable/disable that, at least for certain sites (like your online banking) based on the max-security-level of the driver). And gl compositing window managers. I doubt any of that is worse than any closed src gpu driver. But either way, for really classified/sensitive material you might want to think about a computer with no gpu. I wouldn't be surprised if the NSA knew as much or more about these gpu's as we do. BR, -R > Thanks, > /Thomas > > >> >> Thanks >> David >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On 04/11/2014 02:53 PM, Andy Lutomirski wrote: > > How big of a functionality problem is it? Apparently it doesn't break > 16-bit code on wine. > It breaks *some* 16-bit code. This is actually the reason that 32 bits has the espfix workaround - it wasn't identified as an infoleak at the time. > Since the high bits of esp have been corrupted on x86_64 since the > beginning, there's no regression issue here if an eventual fix writes > less meaningful crap to those bits -- I see no real reason to try to put > the correct values in there. It is a regression vs. the 32-bit kernel, and if we're going to support 16-bit code we should arguably support 16-bit code correctly. This is actually how I stumbled onto this problem in the first place: it broke a compiler test suite for gcc -m16 I was working on. The workaround for *that* was to run in a VM instead. >>> I would have suggested rejecting modify_ldt() entirely, to reduce attack >>> surface, except that some early versions of 32-bit NPTL glibc use >>> modify_ldt() to exclusion of all other methods of establishing the >>> thread pointer, so in order to stay compatible with those we would need >>> to allow 32-bit segments via modify_ldt() still. > > I actually use modify_ldt for amusement: it's the only way I know of to > issue real 32-bit syscalls from 64-bit userspace. Yes, this isn't > really a legitimate use case. That's actually wrong on no less than two levels: 1. You can issue real 32-bit system calls from 64-bit user space simply by invoking int $0x80; it works in 64-bit mode as well. 2. Even if you want to be in 32-bit mode you can simply call via __USER32_CS, you don't need an LDT entry. > Why not just 4k per CPU? Write the pfn to the pte, invlpg, update rsp, > iret. This leaks the CPU number, but that's all. > > To me, this sounds like the easiest solution, so long as rsp is known to > be sufficiently far from a page boundary. > > These ptes could even be read-only to limit the extra exposure to > known-address attacks. > > If you want a fully correct solution, you can use a fancier allocation > policy that can fit quite a few cpus per 4G :) It's damned hard, because you don't have a logical place to *deallocate*. That's what ends up killing you. Also, you will need to port over the equivalent to the espfix recovery code from 32 bits (what happens if IRET takes an exception), so it is nontrivial. >>> d. Trampoline in user space >>> >>> A return to the vdso with values set up in registers r8-r15 would enable >>> a trampoline in user space. Unfortunately there is no way >>> to do a far JMP entirely with register state so this would require >>> touching user space memory, possibly in an unsafe manner. >>> >>> The most likely variant is to use the address of the 16-bit user stack >>> and simply hope that this is a safe thing to do. >>> >>> This appears to be the most feasible workaround if a workaround is >>> deemed necessary. > > Eww. I don't think any of the options are anything but. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Smack: adds smackfs/ptrace interface
On 3/11/2014 9:07 AM, Lukasz Pawelczyk wrote:
> This allows to limit ptrace beyond the regular smack access rules.
> It adds a smackfs/ptrace interface that allows smack to be configured
> to require equal smack labels for PTRACE_MODE_ATTACH access.
> See the changes in Documentation/security/Smack.txt below for details.
>
> Signed-off-by: Lukasz Pawelczyk
> Signed-off-by: Rafal Krypa
Acked-by: Casey Schaufler
Applied to git://git.gitorious.org/smack-next/kernel.git smack-for-3.16
> ---
> Documentation/security/Smack.txt | 10 ++
> security/smack/smack.h | 9 +
> security/smack/smack_access.c| 5 ++-
> security/smack/smack_lsm.c | 22 +++-
> security/smack/smackfs.c | 74
>
> 5 files changed, 118 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/security/Smack.txt
> b/Documentation/security/Smack.txt
> index 7a2d30c..5597917 100644
> --- a/Documentation/security/Smack.txt
> +++ b/Documentation/security/Smack.txt
> @@ -204,6 +204,16 @@ onlycap
> these capabilities are effective at for processes with any
> label. The value is set by writing the desired label to the
> file or cleared by writing "-" to the file.
> +ptrace
> + This is used to define the current ptrace policy
> + 0 - default: this is the policy that relies on smack access rules.
> + For the PTRACE_READ a subject needs to have a read access on
> + object. For the PTRACE_ATTACH a read-write access is required.
> + 1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is
> + only allowed when subject's and object's labels are equal.
> + PTRACE_READ is not affected. Can be overriden with CAP_SYS_PTRACE.
> + 2 - draconian: this policy behaves like the 'exact' above with an
> + exception that it can't be overriden with CAP_SYS_PTRACE.
> revoke-subject
> Writing a Smack label here sets the access to '-' for all access
> rules with that subject label.
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index b9dfc4e..fade085 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -177,6 +177,14 @@ struct smk_port_label {
> #define SMACK_CIPSO_MAXCATNUM 184 /* 23 * 8 */
>
> /*
> + * Ptrace rules
> + */
> +#define SMACK_PTRACE_DEFAULT 0
> +#define SMACK_PTRACE_EXACT 1
> +#define SMACK_PTRACE_DRACONIAN 2
> +#define SMACK_PTRACE_MAX SMACK_PTRACE_DRACONIAN
> +
> +/*
> * Flags for untraditional access modes.
> * It shouldn't be necessary to avoid conflicts with definitions
> * in fs.h, but do so anyway.
> @@ -245,6 +253,7 @@ extern struct smack_known *smack_net_ambient;
> extern struct smack_known *smack_onlycap;
> extern struct smack_known *smack_syslog_label;
> extern const char *smack_cipso_option;
> +extern int smack_ptrace_rule;
>
> extern struct smack_known smack_known_floor;
> extern struct smack_known smack_known_hat;
> diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
> index f161deb..c062e94 100644
> --- a/security/smack/smack_access.c
> +++ b/security/smack/smack_access.c
> @@ -304,7 +304,10 @@ static void smack_log_callback(struct audit_buffer *ab,
> void *a)
> audit_log_untrustedstring(ab, sad->subject);
> audit_log_format(ab, " object=");
> audit_log_untrustedstring(ab, sad->object);
> - audit_log_format(ab, " requested=%s", sad->request);
> + if (sad->request[0] == '\0')
> + audit_log_format(ab, " labels_differ");
> + else
> + audit_log_format(ab, " requested=%s", sad->request);
> }
>
> /**
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 3da13fd..1876bfc 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -178,7 +178,8 @@ static inline unsigned int smk_ptrace_mode(unsigned int
> mode)
> /**
> * smk_ptrace_rule_check - helper for ptrace access
> * @tracer: tracer process
> - * @tracee_label: label of the process that's about to be traced
> + * @tracee_label: label of the process that's about to be traced,
> + *the pointer must originate from smack structures
> * @mode: ptrace attachment mode (PTRACE_MODE_*)
> * @func: name of the function that called us, used for audit
> *
> @@ -201,6 +202,25 @@ static int smk_ptrace_rule_check(struct task_struct
> *tracer, char *tracee_label,
> tsp = task_security(tracer);
> skp = smk_of_task(tsp);
>
> + if ((mode & PTRACE_MODE_ATTACH) &&
> + (smack_ptrace_rule == SMACK_PTRACE_EXACT ||
> + smack_ptrace_rule == SMACK_PTRACE_DRACONIAN)) {
> + if (skp->smk_known == tracee_label)
> + rc = 0;
> + else if (smack_ptrace_rule == SMACK_PTRACE_DRACONIAN)
> + rc = -EACCES;
> + else if (capable(CAP_SYS_PTRACE))
> + rc = 0;
> + else
> +
Re: [GIT PULL] regulator fixes for v3.15
On Fri, Apr 11, 2014 at 01:32:59PM -0700, Linus Torvalds wrote: > On Fri, Apr 11, 2014 at 1:30 PM, Linus Torvalds > wrote: > > Not an immediate problem, but have you tested just adding a simple > > "git fetch" from my repo to your scripts? > Oh, actually, the problem may just be that back-merge you have. When > those cause multiple merge bases, "git diff" can no longer reliably > generate a diff, since there is no clear base for it. And then "git > fetch" to update my current state won't likely help, since the problem > isn't that you don't see my previous pull, the problem is that the > base isn't unique any more. Yeah, I'm pretty sure the problem is the actual back merge - the shortlog is doing the right thing for example. I did in fact have a copy of your merge in my tree, that's how the shortlog turned out right in this round of pull requests. I just need to arrange not to have the back merge either through being more sensible about what I ask you to pull or by improving the scripts. signature.asc Description: Digital signature
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On 04/11/2014 02:24 PM, H. Peter Anvin wrote: > On 04/11/2014 02:16 PM, Andy Lutomirski wrote: >> I wonder if there's an easy-ish good-enough fix: >> >> Allocate some percpu space in the fixmap. (OK, this is ugly, but >> kvmclock already does it, so it's possible.) To return to 16-bit >> userspace, make sure interrupts are off, copy the whole iret descriptor >> to the current cpu's fixmap space, change rsp to point to that space, >> and then do the iret. >> >> This won't restore the correct value to the high bits of [er]sp, but it >> will at least stop leaking anything interesting to userspace. >> > > This would fix the infoleak, at the cost of allocating a chunk of memory > for each CPU. It doesn't fix the functionality problem. > > If we're going to do a workaround I would prefer to do something that > fixes both, but it is highly nontrivial. > > This is a writeup I did to a select audience before this was public: > >> Hello, >> >> This is both a functionality problem (16-bit code gets the upper bits of >> %esp corrupted when the kernel is invoked) and an information leak. The >> 32-bit workaround was labeled as a fix for the functionality problem, >> but it of course also addresses the leak. How big of a functionality problem is it? Apparently it doesn't break 16-bit code on wine. Since the high bits of esp have been corrupted on x86_64 since the beginning, there's no regression issue here if an eventual fix writes less meaningful crap to those bits -- I see no real reason to try to put the correct values in there. >> I would have suggested rejecting modify_ldt() entirely, to reduce attack >> surface, except that some early versions of 32-bit NPTL glibc use >> modify_ldt() to exclusion of all other methods of establishing the >> thread pointer, so in order to stay compatible with those we would need >> to allow 32-bit segments via modify_ldt() still. I actually use modify_ldt for amusement: it's the only way I know of to issue real 32-bit syscalls from 64-bit userspace. Yes, this isn't really a legitimate use case. >> >> a. Using paging in a similar way to the 32-bit segment base workaround >> >> This one requires a very large swath of virtual user space (depending on >> allocation policy, as much as 4 GiB per CPU.) The "per CPU" requirement >> comes in as locking is not feasible -- as we return to user space there >> is nowhere to release the lock. Why not just 4k per CPU? Write the pfn to the pte, invlpg, update rsp, iret. This leaks the CPU number, but that's all. To me, this sounds like the easiest solution, so long as rsp is known to be sufficiently far from a page boundary. These ptes could even be read-only to limit the extra exposure to known-address attacks. If you want a fully correct solution, you can use a fancier allocation policy that can fit quite a few cpus per 4G :) >> >> d. Trampoline in user space >> >> A return to the vdso with values set up in registers r8-r15 would enable >> a trampoline in user space. Unfortunately there is no way >> to do a far JMP entirely with register state so this would require >> touching user space memory, possibly in an unsafe manner. >> >> The most likely variant is to use the address of the 16-bit user stack >> and simply hope that this is a safe thing to do. >> >> This appears to be the most feasible workaround if a workaround is >> deemed necessary. Eww. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
Quoting Andy Lutomirski (l...@amacapital.net): > On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn wrote: > > Quoting Andy Lutomirski (l...@amacapital.net): > >> I'm starting to think that we need to extend dumpable to something > >> much more general like a list of struct creds that someone needs to be > >> able to ptrace, *in addition to current creds* in order to access > >> sensitive /proc files, coredumps, etc. If you get started as setuid, > > > > Hm, yeah, this sort of makes sense. > > > >> then you start with two struct creds in the list (or maybe just your > >> euid and uid). If you get started !setuid, then your initial creds > >> are in the list. It's possible that few or no things will need to > >> change that list after execve. > >> > >> If all of the entries and current->cred are in the same user_ns, then > >> we can dump as userns root. If they're in different usernses, then we > >> dump as global root or maybe the common ancestor root. > >> setuid(getuid()) and other such nastiness may have to empty the list, > >> or maybe we can just use a prctl for that. > > > > A few questions, > > > > 1. is there any other action which would trigger adding a new cred to > > the ist? > > I don't think so. Anyone who can ptrace you from the start can > corrupt you such that you leak rights even if some future action > prevents new ptracers from attaching. > > OTOH, it might be nice for something like an HTTPS server to be able > to fork and shove its private key into the child, while preventing > anyone from ptracing the child. But doing this securely without help > from someone with a different uid might be impossible anyway. > > > > > 2. would execve clear (and re-init) the list of creds? > > Probably. Thoughts? Yeah it seems to me it should be re-initialized, with a cred added to the list for every open fd. > We could have a way to ask execve not to reinit the list. Such a > mechanism would have to require no_new_privs to prevent a > straightforward attack on any setuid binary. If we don't add a cred for every open fd, then I think we need this. If we do, then I'm not sure this makes sense. > We's also want PR_SET_DUMPABLE or a new prctl to be able reset the > list to contain just current-.cred, I think. Yeah PR_SET_DUMPABLE should reset it, agreed. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] SMACK: Fix handling value==NULL in post setxattr
On 4/3/2014 4:48 AM, José Bollo wrote:
> The function `smack_inode_post_setxattr` is called each
> time that a setxattr is done, for any value of name.
> The kernel allow to put value==NULL when size==0
> to set an empty attribute value. The systematic
> call to smk_import_entry was causing the dereference
> of a NULL pointer hence a KERNEL PANIC!
>
> The problem can be produced easily by issuing the
> command `setfattr -n user.data file` under bash prompt
> when SMACK is active.
>
> Moving the call to smk_import_entry as proposed by this
> patch is correcting the behaviour because the function
> smack_inode_post_setxattr is called for the SMACK's
> attributes only if the function smack_inode_setxattr validated
> the value and its size (what will not be the case when size==0).
>
> It also has a benefical effect to not fill the smack hash
> with garbage values coming from any extended attribute
> write.
>
> Change-Id: Iaf0039c2be9bccb6cee11c24a3b44d209101fe47
> Signed-off-by: José Bollo
Acked-by: Casey Schaufler
Applied to git://git.gitorious.org/smack-next/kernel.git smack-for-3.16
> ---
> security/smack/smack_lsm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 3f01cf5..28d482c 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -893,18 +893,20 @@ static void smack_inode_post_setxattr(struct dentry
> *dentry, const char *name,
> return;
> }
>
> - skp = smk_import_entry(value, size);
> if (strcmp(name, XATTR_NAME_SMACK) == 0) {
> + skp = smk_import_entry(value, size);
> if (skp != NULL)
> isp->smk_inode = skp->smk_known;
> else
> isp->smk_inode = smack_known_invalid.smk_known;
> } else if (strcmp(name, XATTR_NAME_SMACKEXEC) == 0) {
> + skp = smk_import_entry(value, size);
> if (skp != NULL)
> isp->smk_task = skp;
> else
> isp->smk_task = _known_invalid;
> } else if (strcmp(name, XATTR_NAME_SMACKMMAP) == 0) {
> + skp = smk_import_entry(value, size);
> if (skp != NULL)
> isp->smk_mmap = skp;
> else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] smack lsm bug fixes
On 2/20/2014 2:15 AM, Pankaj Kumar wrote:
> From: Pankaj Kumar
>
> 1. In order to remove any SMACK extended attribute from a file, a user
> should have CAP_MAC_ADMIN capability. But any user without this
> capability is able to remove SMACK64MMAP security attribute. This error
> has been corrected by a modification in smack_inode_removexattr hook.
>
> 2. While setting extended attribute in smack_inode_setsecurity hook,
> '-EACCES' error is returned if extended attribute size or value is not
> correct. This is wrong error rather this is invalid extended attribute
> case. Corrected error '-EINVAL' shall be returned.
>
> Signed-off-by: Pankaj Kumar
> Signed-off-by: Himanshu Shukla
Acked-by: Casey Schaufler
Applied to git://git.gitorious.org/smack-next/kernel.git smack-for-3.16
> ---
> security/smack/smack_lsm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 14f52be..e1b1650 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -938,7 +938,7 @@ static int smack_inode_removexattr(struct dentry
> *dentry, const char *name)
> strcmp(name, XATTR_NAME_SMACKIPOUT) == 0 ||
> strcmp(name, XATTR_NAME_SMACKEXEC) == 0 ||
> strcmp(name, XATTR_NAME_SMACKTRANSMUTE) == 0 ||
> -strcmp(name, XATTR_NAME_SMACKMMAP)) {
> +strcmp(name, XATTR_NAME_SMACKMMAP) == 0) {
> if (!smack_privileged(CAP_MAC_ADMIN))
> rc = -EPERM;
> } else
> @@ -2076,7 +2076,7 @@ static int smack_inode_setsecurity(struct inode
> *inode, const char *name,
> int rc = 0;
>
> if (value == NULL || size > SMK_LONGLABEL || size == 0)
> -return -EACCES;
> +return -EINVAL;
>
> skp = smk_import_entry(value, size);
> if (skp == NULL)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Smack: unify all ptrace accesses in the smack
On 3/11/2014 9:07 AM, Lukasz Pawelczyk wrote:
> The decision whether we can trace a process is made in the following
> functions:
> smack_ptrace_traceme()
> smack_ptrace_access_check()
> smack_bprm_set_creds() (in case the proces is traced)
>
> This patch unifies all those decisions by introducing one function that
> checks whether ptrace is allowed: smk_ptrace_rule_check().
>
> This makes possible to actually trace with TRACEME where first the
> TRACEME itself must be allowed and then exec() on a traced process.
>
> Additional bugs fixed:
> - The decision is made according to the mode parameter that is now correctly
> translated from PTRACE_MODE_* to MAY_* instead of being treated 1:1.
> PTRACE_MODE_READ requires MAY_READ.
> PTRACE_MODE_ATTACH requires MAY_READWRITE.
> - Add a smack audit log in case of exec() refused by bprm_set_creds().
> - Honor the PTRACE_MODE_NOAUDIT flag and don't put smack audit info
> in case this flag is set.
>
> Signed-off-by: Lukasz Pawelczyk
> Signed-off-by: Rafal Krypa
Acked-by: Casey Schaufler
Applied to git://git.gitorious.org/smack-next/kernel.git smack-for-3.16
> ---
> security/smack/smack_lsm.c | 84
> +++---
> 1 file changed, 71 insertions(+), 13 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 48d61f6..3da13fd 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -157,6 +157,54 @@ static int smk_copy_rules(struct list_head *nhead,
> struct list_head *ohead,
> return rc;
> }
>
> +/**
> + * smk_ptrace_mode - helper function for converting PTRACE_MODE_* into MAY_*
> + * @mode - input mode in form of PTRACE_MODE_*
> + *
> + * Returns a converted MAY_* mode usable by smack rules
> + */
> +static inline unsigned int smk_ptrace_mode(unsigned int mode)
> +{
> + switch (mode) {
> + case PTRACE_MODE_READ:
> + return MAY_READ;
> + case PTRACE_MODE_ATTACH:
> + return MAY_READWRITE;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * smk_ptrace_rule_check - helper for ptrace access
> + * @tracer: tracer process
> + * @tracee_label: label of the process that's about to be traced
> + * @mode: ptrace attachment mode (PTRACE_MODE_*)
> + * @func: name of the function that called us, used for audit
> + *
> + * Returns 0 on access granted, -error on error
> + */
> +static int smk_ptrace_rule_check(struct task_struct *tracer, char
> *tracee_label,
> + unsigned int mode, const char *func)
> +{
> + int rc;
> + struct smk_audit_info ad, *saip = NULL;
> + struct task_smack *tsp;
> + struct smack_known *skp;
> +
> + if ((mode & PTRACE_MODE_NOAUDIT) == 0) {
> + smk_ad_init(, func, LSM_AUDIT_DATA_TASK);
> + smk_ad_setfield_u_tsk(, tracer);
> + saip =
> + }
> +
> + tsp = task_security(tracer);
> + skp = smk_of_task(tsp);
> +
> + rc = smk_tskacc(tsp, tracee_label, smk_ptrace_mode(mode), saip);
> + return rc;
> +}
> +
> /*
> * LSM hooks.
> * We he, that is fun!
> @@ -165,16 +213,15 @@ static int smk_copy_rules(struct list_head *nhead,
> struct list_head *ohead,
> /**
> * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
> * @ctp: child task pointer
> - * @mode: ptrace attachment mode
> + * @mode: ptrace attachment mode (PTRACE_MODE_*)
> *
> * Returns 0 if access is OK, an error code otherwise
> *
> - * Do the capability checks, and require read and write.
> + * Do the capability checks.
> */
> static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int
> mode)
> {
> int rc;
> - struct smk_audit_info ad;
> struct smack_known *skp;
>
> rc = cap_ptrace_access_check(ctp, mode);
> @@ -182,10 +229,8 @@ static int smack_ptrace_access_check(struct task_struct
> *ctp, unsigned int mode)
> return rc;
>
> skp = smk_of_task(task_security(ctp));
> - smk_ad_init(, __func__, LSM_AUDIT_DATA_TASK);
> - smk_ad_setfield_u_tsk(, ctp);
>
> - rc = smk_curacc(skp->smk_known, mode, );
> + rc = smk_ptrace_rule_check(current, skp->smk_known, mode, __func__);
> return rc;
> }
>
> @@ -195,12 +240,11 @@ static int smack_ptrace_access_check(struct task_struct
> *ctp, unsigned int mode)
> *
> * Returns 0 if access is OK, an error code otherwise
> *
> - * Do the capability checks, and require read and write.
> + * Do the capability checks, and require PTRACE_MODE_ATTACH.
> */
> static int smack_ptrace_traceme(struct task_struct *ptp)
> {
> int rc;
> - struct smk_audit_info ad;
> struct smack_known *skp;
>
> rc = cap_ptrace_traceme(ptp);
> @@ -208,10 +252,9 @@ static int smack_ptrace_traceme(struct task_struct *ptp)
> return rc;
>
> skp = smk_of_task(current_security());
> - smk_ad_init(, __func__, LSM_AUDIT_DATA_TASK);
> - smk_ad_setfield_u_tsk(,
Re: [PATCH 1/3] Smack: fix the subject/object order in smack_ptrace_traceme()
On 3/11/2014 9:07 AM, Lukasz Pawelczyk wrote:
> The order of subject/object is currently reversed in
> smack_ptrace_traceme(). It is currently checked if the tracee has a
> capability to trace tracer and according to this rule a decision is made
> whether the tracer will be allowed to trace tracee.
>
> Signed-off-by: Lukasz Pawelczyk
> Signed-off-by: Rafal Krypa
Acked-by: Casey Schaufler
Applied to git://git.gitorious.org/smack-next/kernel.git smack-for-3.16
> ---
> security/smack/smack.h| 1 +
> security/smack/smack_access.c | 33 ++---
> security/smack/smack_lsm.c| 4 ++--
> 3 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index d072fd3..b9dfc4e 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -225,6 +225,7 @@ struct inode_smack *new_inode_smack(char *);
> */
> int smk_access_entry(char *, char *, struct list_head *);
> int smk_access(struct smack_known *, char *, int, struct smk_audit_info *);
> +int smk_tskacc(struct task_smack *, char *, u32, struct smk_audit_info *);
> int smk_curacc(char *, u32, struct smk_audit_info *);
> struct smack_known *smack_from_secid(const u32);
> char *smk_parse_smack(const char *string, int len);
> diff --git a/security/smack/smack_access.c b/security/smack/smack_access.c
> index 14293cd..f161deb 100644
> --- a/security/smack/smack_access.c
> +++ b/security/smack/smack_access.c
> @@ -192,20 +192,21 @@ out_audit:
> }
>
> /**
> - * smk_curacc - determine if current has a specific access to an object
> + * smk_tskacc - determine if a task has a specific access to an object
> + * @tsp: a pointer to the subject task
> * @obj_label: a pointer to the object's Smack label
> * @mode: the access requested, in "MAY" format
> * @a : common audit data
> *
> - * This function checks the current subject label/object label pair
> + * This function checks the subject task's label/object label pair
> * in the access rule list and returns 0 if the access is permitted,
> - * non zero otherwise. It allows that current may have the capability
> + * non zero otherwise. It allows that the task may have the capability
> * to override the rules.
> */
> -int smk_curacc(char *obj_label, u32 mode, struct smk_audit_info *a)
> +int smk_tskacc(struct task_smack *subject, char *obj_label,
> +u32 mode, struct smk_audit_info *a)
> {
> - struct task_smack *tsp = current_security();
> - struct smack_known *skp = smk_of_task(tsp);
> + struct smack_known *skp = smk_of_task(subject);
> int may;
> int rc;
>
> @@ -219,7 +220,7 @@ int smk_curacc(char *obj_label, u32 mode, struct
> smk_audit_info *a)
>* it can further restrict access.
>*/
> may = smk_access_entry(skp->smk_known, obj_label,
> - >smk_rules);
> + >smk_rules);
> if (may < 0)
> goto out_audit;
> if ((mode & may) == mode)
> @@ -241,6 +242,24 @@ out_audit:
> return rc;
> }
>
> +/**
> + * smk_curacc - determine if current has a specific access to an object
> + * @obj_label: a pointer to the object's Smack label
> + * @mode: the access requested, in "MAY" format
> + * @a : common audit data
> + *
> + * This function checks the current subject label/object label pair
> + * in the access rule list and returns 0 if the access is permitted,
> + * non zero otherwise. It allows that current may have the capability
> + * to override the rules.
> + */
> +int smk_curacc(char *obj_label, u32 mode, struct smk_audit_info *a)
> +{
> + struct task_smack *tsp = current_security();
> +
> + return smk_tskacc(tsp, obj_label, mode, a);
> +}
> +
> #ifdef CONFIG_AUDIT
> /**
> * smack_str_from_perm : helper to transalate an int to a
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index d814e35..48d61f6 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -207,11 +207,11 @@ static int smack_ptrace_traceme(struct task_struct *ptp)
> if (rc != 0)
> return rc;
>
> - skp = smk_of_task(task_security(ptp));
> + skp = smk_of_task(current_security());
> smk_ad_init(, __func__, LSM_AUDIT_DATA_TASK);
> smk_ad_setfield_u_tsk(, ptp);
>
> - rc = smk_curacc(skp->smk_known, MAY_READWRITE, );
> + rc = smk_tskacc(ptp, skp->smk_known, MAY_READWRITE, );
> return rc;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/23] 3.14.1-stable review
On 04/11/2014 09:11 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.1 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Apr 13 16:11:46 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 121 skipped: 4 fail: 1 Failing build is powerpc:allmodconfig. Error log: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 Qemu tests all passed. Results match the build results from 3.14, and are therefore as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] spi fixes for v3.15
On Fri, Apr 11, 2014 at 01:41:56PM -0700, Linus Torvalds wrote: > On Fri, Apr 11, 2014 at 3:56 AM, Mark Brown wrote: > > Same issue as on the regulator pull request with the entire diffstat for > > the original pull request for this merge window has appeared - like I > > say I will try to fix the scripts as it's annoying and unclear. > Yeah, looking at this, the problem does seem to be that extraneous > merge. I'm not sure why you did that "Merge tag 'spi-v3.15' into > spi-linus" at all, but it basically acts as an indirect back-merge > giving you two different merge bases. Indeed. > You seem to start your development by doing a merge of that tag that > you sent me. Why? Why not just start *at* the tag you sent me, not at > that extraneous merge of that tag and v3.14. What the script is doing is starting from your latest tag, merging any tags I've sent you in the meantime and then merging any additional topic branches. I'm not doing any actual development on the resulting branch, only on topic branches. The tags get merged first to suppress repeated merges of the same topic branch if I've sent a prior pull request been tagged yet and I use your latest tag to pick up fixes from other trees and make sure I'm not tripping over things I sent you before. Usually this works fine since most of the time either your latest tag contains the last thing I sent you or my tag contains your most recent tag and either way there's no back merge. What's gone wrong this time around is that I sent you my initial pull requests based off the last -rc rather than off the release tag, the script didn't cope well with that and picked the wrong thing to base the merge off. If I'd respun the merge before I sent the pull requests it'd all be working as expected, I need to either just do that or teach the script to be more sensible about picking where it starts building the merge from. signature.asc Description: Digital signature
Re: [PATCH 3.13 00/65] 3.13.10-stable review
On 04/11/2014 09:10 AM, Greg Kroah-Hartman wrote: NOTE This is probably going to be the last 3.13.y kernel release. There _might_ be one more after this, but given my travel schedule for the next few weeks, don't count on it. Please move to the 3.14 kernel tree as soon as possible. This is the start of the stable review cycle for the 3.13.10 release. There are 65 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Apr 13 16:09:42 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 122 skipped: 4 fail: 0 Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/41] 3.10.37-stable review
On 04/11/2014 09:09 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.37 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Apr 13 16:09:00 UTC 2014. Anything received after that time might be too late. Build results: total: 126 pass: 122 skipped: 4 fail: 0 Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] shm: add sealing API
Hi On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski wrote: > A quick grep of the kernel tree finds exactly zero code paths > incrementing i_mmap_writable outside of mmap and fork. > > Or do you mean a different kind of write ref? What am I missing here? Sorry, I meant i_writecount. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
On 04/10/2014 11:44 AM, Clark Williams wrote: On Wed, 9 Apr 2014 15:19:22 -0400 Steven Rostedt wrote: This patch is built on top of the two other patches that I posted earlier, which should not be as controversial. If you have any benchmark on large machines I would be very happy if you could test this patch against the unpatched version of -rt. Cheers, -- Steve Steven I wrote a program named whack_mmap_sem which creates a large (4GB) buffer, then creates 2 x ncpus threads that are affined across all the available cpus. These threads then randomly write into the buffer, which should cause page faults galore. I then built the following kernel configs: vanilla-3.13.15 - no RT patches applied rt-3.12.15 - PREEMPT_RT patchset rt-3.12.15-fixes - PREEMPT_RT + rwsem fixes rt-3.12.15-multi - PREEMPT_RT + rwsem fixes + rwsem-multi patch My test h/w was a Dell R520 with a 6-core Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz (hyperthreaded). So whack_mmap_sem created 24 threads which all partied in the 4GB address range. I ran whack_mmap_sem with the argument -w 10 which means each thread does 100k writes to random locations inside the buffer and then did five runs per each kernel. At the end of the run whack_mmap_sem prints out the time of the run in microseconds. The means of each group of five test runs are: vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than vanilla) rt-fixes.log: 10062027 (8.3 x slower than vanilla) rt-multi.log: 3179582 (2.x x slower than vanilla) Hi I ran Clark's test on a machine with 32 CPUs: 2 Sockets, 8 core/socket + HT On this machine I ran 5 different kernels: Vanilla: 3.12.15 - Vanilla RT: 3.12.15 + Preempt-RT 3.12.15-rt25 FIX: RT + rwsem fixes from rostedt Multi: FIX + Multi-reader PI Multi -FULL: Multi + CONFIG_PREEMPT=y I ran the test with the same parameters that Clark used, 100 iterations for each kernel. For each kernel I measure the min and max execution time, along with the avg execution time and the standard deviation. The result was: +---+-+--+--+---+-+ | | Vanilla |RT|FIX | Multi | Multi -FULL | +-+--+--+---+-+ |MIN: | 3806754 | 6092939 | 6324665 | 2633614 | 3867240 | |AVG: | 3875201 | 8162832 | 8007934 | 2736253 | 3961607 | |MAX: | 4062205 | 10951416 | 10574212 | 2972458 | 4139297 | |STDEV: | 47645 | 927839 | 943482 | 52579 | 943482 | +---+-+--+--+---+-+ A comparative of avg case to vanilla: RT- 2.10x (slower) FIX - 2.06x (slower) Multi - 0.70x (faster?) Multi no PREEMPT_FULL - 1.02x (equals?) As we can see, the patch gave good results on Preempt-RT, but my results was a little bit weird, because the PREEMPT-RT + Multi patch became faster than vanilla. In the standard deviation, the patch showed a good result as well, with the patch the std dev became ~17x smaller than on RT kernel without the patch, which means less jitter. -- Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH_v8 0/2] arm64: Add audit support
On 03/15/2014 01:49 AM, AKASHI Takahiro wrote: (Please apply this patch after my ftrace patch to resolve some conflict on arm64/kernel/ptrace.c, functionally it doesn't depend on ftrace though) This patchset adds system call audit support on arm64. Both 32-bit (AUDIT_ARCH_ARM) and 64-bit tasks (AUDIT_ARCH_AARCH64) are supported. Since arm64 has the exact same set of system calls on LE and BE, we don't care about endianness (or more specifically __AUDIT_ARCH_64BIT bit in AUDIT_ARCH_*). There are some prerequisites for this patch to work correctly: * "audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL" patch * "audit: generic compat system call audit support" patch * "arm64: __NR_* definitions for compat syscalls" patch from Catalin * "arm64: make a single hook to syscall_trace() for all syscall features" patch * "arm64: split syscall_trace() into separate functions for enter/exit" patch * "arm64: Add regs_return_value() in syscall.h" patch * "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h" patch * userspace audit tool (v2.3.2 + my patch for arm64) and the 2/2 patch won't apply to arch/arm64/kernel/ptrace.c without the patch from [PATCH v7 7/7] arm64: ftrace: Add system call tracepoint; My question: do you need all 7 patches from arm64: Add ftrace support as well for this audit patch to work, or just this 7/7 patch ? Please review them as well for better understandings. This code was tested on both 32-bit and 64-bit LE userland in the following two ways: 1) basic operations with auditctl/autrace # auditctl -a exit,always -S openat -F path=/etc/inittab # auditctl -a exit,always -F dir=/tmp -F perm=rw # auditctl -a task,always # autrace /bin/ls by comparing output from autrace with one from strace 2) audit-test-code (+ my workarounds for arm/arm64) by running "audit-tool", "filter" and "syscalls" test categories. Changes v7 -> v8: * aligned with the change in "audit: generic compat system call audit support" v5 [1/2] * aligned with the change in "arm64: split syscall_trace() into separate functions for enter/exit" v5 [2/2] Changes v6 -> v7: * changed an include file in syscall.h from to [1/2] * aligned with the patch, "arm64: split syscall_trace() into separate functions for enter/exit" [2/2] Changes v5 -> v6: * removed and put "arm64: Add regs_return_value() in syscall.h" patch into a separate set * aligned with the change in "arm64: make a single hook to syscall_trace() for all syscall features" v3 [1/2] Changes v4 -> v5: * rebased to 3.14-rcX * added a guard against TIF_SYSCALL_AUDIT [3/3] * aligned with the change in "arm64: make a single hook to syscall_trace() for all syscall features" v2 [3/3] Changes v3 -> v4: * Modified to sync with the patch, "make a single hook to syscall_trace() for all syscall features" * aligned with "audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL" patch Changes v2 -> v3: * Remove asm/audit.h. See "generic compat syscall audit support" patch v4 * Remove endianness dependency, ie. AUDIT_ARCH_ARMEB/AARCH64EB. * Remove kernel/syscalls/Makefile which was used to create unistd32.h. See Catalin's "Add __NR_* definitions for compat syscalls" patch Changes v1 -> v2: * Modified to utilize "generic compat system call audit" [3/6, 4/6, 5/6] Please note that a required header, unistd_32.h, is automatically generated from unistd32.h. * Refer to regs->orig_x0 instead of regs->x0 as the first argument of system call in audit_syscall_entry() [6/6] * Include "Add regs_return_value() in syscall.h" patch [2/6], which was not intentionally included in v1 because it could be added by "kprobes support". AKASHI Takahiro (2): arm64: Add audit support arm64: audit: Add audit hook in syscall_trace_enter/exit() arch/arm64/Kconfig | 2 ++ arch/arm64/include/asm/syscall.h | 15 +++ arch/arm64/kernel/ptrace.c | 7 +++ include/uapi/linux/audit.h | 1 + 4 files changed, 25 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] shm: add sealing API
On 04/11/2014 02:31 PM, David Herrmann wrote: > Hi > > On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby wrote: >> Exactly. For O_DIRECT, that would be the call to get_user_pages_fast() >> from dio_refill_pages() in fs/direct-io.c, which is ultimately called >> from blkdev_direct_IO(). > > If you drop mmap_sem after pinning a page without taking a write-ref, > you break i_mmap_writable / VM_DENYWRITE. In memfd I rely on > i_mmap_writable to work, same thing is done by exec() (and the old, > now disabled, MAP_DENYWRITE). > > I don't know whether I should care. I mean, everyone pinning pages and > writing to it without holding the mmap_sem has to take a write-ref for > each page or it breaks i_mmap_writable. So this seems to be a bug in > direct-IO, not in anyone relying on it, right? A quick grep of the kernel tree finds exactly zero code paths incrementing i_mmap_writable outside of mmap and fork. Or do you mean a different kind of write ref? What am I missing here? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On Fri, Apr 11, 2014 at 2:16 PM, Andy Lutomirski wrote: > > I wonder if there's an easy-ish good-enough fix: Heh. Yes. Check the thread on lkml about three weeks ago under the subject "x86-64: Information leak: kernel stack address leaks to user space". It had exactly that as a suggestion. Anyway, I ended up pulling the current change - let's see if anybody even cares. And if somebody *does* care, maybe we can just do a trivial sysctl. If you are running 16-bit apps under wine, the default kernel setup already stops you: the 'mmap_min_addr' being non-zero means that that already will not run. But yeah, I personally don't care about the high bits of rsp one whit, since that has never worked on x86-64. But the information leak needs to be plugged, and a percpu stack can fix that. I'm a bit worried that a percpu stack can cause issues with NMI's, which already have too much complexity in them, so I don't think it's *entirely* trivial to do. And the exception that the 'iretq' can take adds more complexity wrt kernel stack pointer games. Which is why I'm not at all sure it's worth it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] i386: Wire up the renameat2() syscall
Commit-ID: ab0a9358ecf87bb801ce124473e7db713457bec4 Gitweb: http://git.kernel.org/tip/ab0a9358ecf87bb801ce124473e7db713457bec4 Author: Miklos Szeredi AuthorDate: Fri, 11 Apr 2014 12:25:37 +0200 Committer: H. Peter Anvin CommitDate: Fri, 11 Apr 2014 13:59:58 -0700 i386: Wire up the renameat2() syscall The renameat2() system call was only wired up for x86-64. Signed-off-by: Miklos Szeredi Link: http://lkml.kernel.org/r/1397211951-20549-2-git-send-email-mik...@szeredi.hu Cc: H. Peter Anvin Signed-off-by: H. Peter Anvin --- arch/x86/syscalls/syscall_32.tbl | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index 96bc506..d6b8679 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -359,3 +359,4 @@ 350i386finit_modulesys_finit_module 351i386sched_setattr sys_sched_setattr 352i386sched_getattr sys_sched_getattr +353i386renameat2 sys_renameat2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] shm: add sealing API
Hi On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby wrote: > Exactly. For O_DIRECT, that would be the call to get_user_pages_fast() > from dio_refill_pages() in fs/direct-io.c, which is ultimately called > from blkdev_direct_IO(). If you drop mmap_sem after pinning a page without taking a write-ref, you break i_mmap_writable / VM_DENYWRITE. In memfd I rely on i_mmap_writable to work, same thing is done by exec() (and the old, now disabled, MAP_DENYWRITE). I don't know whether I should care. I mean, everyone pinning pages and writing to it without holding the mmap_sem has to take a write-ref for each page or it breaks i_mmap_writable. So this seems to be a bug in direct-IO, not in anyone relying on it, right? Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On 04/11/2014 02:16 PM, Andy Lutomirski wrote:
> On 04/11/2014 11:29 AM, H. Peter Anvin wrote:
>> On 04/11/2014 11:27 AM, Brian Gerst wrote:
>>> Is this bug really still present in modern CPUs? This change breaks
>>> running 16-bit apps in Wine. I have a few really old games I like to
>>> play on occasion, and I don't have a copy of Win 3.11 to put in a VM.
>>
>> It is not a bug, per se, but an architectural definition issue, and it
>> is present in all x86 processors from all vendors.
>>
>> Yes, it does break running 16-bit apps in Wine, although Wine could be
>> modified to put 16-bit apps in a container. However, this is at best a
>> marginal use case.
>
> I wonder if there's an easy-ish good-enough fix:
>
> Allocate some percpu space in the fixmap. (OK, this is ugly, but
> kvmclock already does it, so it's possible.) To return to 16-bit
> userspace, make sure interrupts are off, copy the whole iret descriptor
> to the current cpu's fixmap space, change rsp to point to that space,
> and then do the iret.
>
> This won't restore the correct value to the high bits of [er]sp, but it
> will at least stop leaking anything interesting to userspace.
>
This would fix the infoleak, at the cost of allocating a chunk of memory
for each CPU. It doesn't fix the functionality problem.
If we're going to do a workaround I would prefer to do something that
fixes both, but it is highly nontrivial.
This is a writeup I did to a select audience before this was public:
> Hello,
>
> It appears we have an information leak on x86-64 by which at least bits
> [31:16] of the kernel stack address leaks to user space (some silicon
> including the 64-bit Pentium 4 leaks [63:16]). This is due to the the
> behavior of IRET when returning to a 16-bit segment: IRET restores only
> the bottom 16 bits of the stack pointer.
>
> This is known on 32 bits and we, in fact, have a workaround for it
> ("espfix") there. We do not, however, have the equivalent on 64 bits,
> nor does it seem that it is very easy to construct a workaround (see below.)
>
> This is both a functionality problem (16-bit code gets the upper bits of
> %esp corrupted when the kernel is invoked) and an information leak. The
> 32-bit workaround was labeled as a fix for the functionality problem,
> but it of course also addresses the leak.
>
> On 64 bits, the easiest mitigation seems to be to make modify_ldt()
> refuse to install a 16-bit segment when running on a 64-bit kernel.
> 16-bit support is already somewhat crippled on 64 bits since there is no
> V86 support; obviously, for "full service" support we can always set up
> a virtual machine -- most (but sadly, not all) 64-bit parts are also
> virtualization capable.
>
> I would have suggested rejecting modify_ldt() entirely, to reduce attack
> surface, except that some early versions of 32-bit NPTL glibc use
> modify_ldt() to exclusion of all other methods of establishing the
> thread pointer, so in order to stay compatible with those we would need
> to allow 32-bit segments via modify_ldt() still.
>
> However, there is no doubt this will break some legitimate users of
> 16-bit segments, e.g. Wine for 16-bit Windows apps (which don't work on
> 64-bit Windows either, for what it is worth.)
>
> We may very well have other infoleaks that dwarf this, but the kernel
> stack address is a relatively high value item for exploits.
>
> Some workarounds I have considered:
>
> a. Using paging in a similar way to the 32-bit segment base workaround
>
> This one requires a very large swath of virtual user space (depending on
> allocation policy, as much as 4 GiB per CPU.) The "per CPU" requirement
> comes in as locking is not feasible -- as we return to user space there
> is nowhere to release the lock.
>
> b. Return to user space via compatibility mode
>
> As the kernel lives above the 4 GiB virtual mark, a transition through
> compatibility mode is not practical. This would require the kernel to
> reserve virtual address space below the 4 GiB mark, which may interfere
> with the application, especially an application launched as a 64-bit
> application.
>
> c. Trampoline in kernel space
>
> A trampoline in kernel space is not feasible since all ring transition
> instructions capable of returning to 16-bit mode require the use of the
> stack.
>
> d. Trampoline in user space
>
> A return to the vdso with values set up in registers r8-r15 would enable
> a trampoline in user space. Unfortunately there is no way
> to do a far JMP entirely with register state so this would require
> touching user space memory, possibly in an unsafe manner.
>
> The most likely variant is to use the address of the 16-bit user stack
> and simply hope that this is a safe thing to do.
>
> This appears to be the most feasible workaround if a workaround is
> deemed necessary.
>
> e. Transparently run 16-bit code segments inside a lightweight VMM
>
> The complexity of this solution versus the realized value is staggering.
> It
Re: [PATCH] [v2] mm: pass VM_BUG_ON() reason to dump_page()
On Fri, 2014-04-11 at 13:42 -0700, Dave Hansen wrote: > Changes from v1: > * Fix tabs before spaces in the multi-line #define > > -- > From: Dave Hansen > > I recently added a patch to let folks pass a "reason" string > dump_page() which gets dumped out along with the page's data. > This essentially saves the bug-reader a trip in to the source > to figure out why we BUG_ON()'d. > > The new VM_BUG_ON_PAGE() passes in NULL for "reason". It seems > like we might as well pass the BUG_ON() condition if we have it. > This will bloat kernels a bit with ~160 new strings, but this > is all under a debugging option anyway. > > page:ea0008560280 count:1 mapcount:0 mapping:(null) index:0x0 > page flags: 0xbfffc01(locked) > page dumped because: VM_BUG_ON_PAGE(PageLocked(page)) > [ cut here ] > kernel BUG at /home/davehans/linux.git/mm/filemap.c:464! > invalid opcode: [#1] SMP > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #251 > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > ... > > > Signed-off-by: Dave Hansen > Acked-by: Kirill A. Shutemov Acked-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] mmc: Delay the card_event callback into the mmc_rescan worker
On 9 April 2014 01:56, Ulf Hansson wrote:
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 098374b..ff7fd2e 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -2421,6 +2421,11 @@ void mmc_rescan(struct work_struct *work)
>> container_of(work, struct mmc_host, detect.work);
>> int i;
>>
>> + if (host->trigger_card_event && host->ops->card_event) {
>> + host->ops->card_event(host);
>> + host->trigger_card_event = false;
>> + }
>> +
>
> So this might be a stupid question. :-)
>
> Could you elaborate on why the host->ops->card_event then is needed at
> all. Why can't host drivers use host->ops->get_cd to perform the
> actions they need?
>
> The reason for bringing this up, is because this patch moves the
> invokes of the these callbacks quite close to each other. Earlier they
> were more separated.
Thanks for the question. I looked at the code and I don't think
host->ops->get_cd would work in my case.
I proposed this change based on behaviour exhibited by
sdhci-bcm-kona.c (mutex sleeps in the IRQ handler cause "scheduling
while atomic" errors). The idea of this patch is to move the card
event processing (which does the actual card detection) out of the
interrupt handler, so the mutex in my callback can be used without
problems.
https://git.linaro.org/landing-teams/working/broadcom/kernel.git/blob/refs/heads/review/mmc-card-event:/drivers/mmc/host/sdhci-bcm-kona.c#l160
An earlier proposal to fix this issue was to simply replace the mutex
with a spinlock in sdhci-bcm-kona.c, but that was not seen as good
solution. (https://lkml.org/lkml/2014/3/5/527)
Based on your question, I looked through the code some more. From what
I can tell, SDHCI hosts have their host->ops->get_cd set to
sdhci_get_cd() in sdhci.c (specifically by sdhci_add_host()). So,
get_cd is not available to me to customize.
Maybe we need a different solution from what I proposed above, but I
don't think get_cd will do the trick.
I can see how moving card_event and get_cd closer together, like I
have done, can be a reason for concern. On the flip-side, de-coupling
card_event from IRQ processing seems to be beneficial.
What do you think?
Regards,
-Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
On 04/11/2014 11:29 AM, H. Peter Anvin wrote: > On 04/11/2014 11:27 AM, Brian Gerst wrote: >> Is this bug really still present in modern CPUs? This change breaks >> running 16-bit apps in Wine. I have a few really old games I like to >> play on occasion, and I don't have a copy of Win 3.11 to put in a VM. > > It is not a bug, per se, but an architectural definition issue, and it > is present in all x86 processors from all vendors. > > Yes, it does break running 16-bit apps in Wine, although Wine could be > modified to put 16-bit apps in a container. However, this is at best a > marginal use case. I wonder if there's an easy-ish good-enough fix: Allocate some percpu space in the fixmap. (OK, this is ugly, but kvmclock already does it, so it's possible.) To return to 16-bit userspace, make sure interrupts are off, copy the whole iret descriptor to the current cpu's fixmap space, change rsp to point to that space, and then do the iret. This won't restore the correct value to the high bits of [er]sp, but it will at least stop leaking anything interesting to userspace. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DRM security flaws and security levels.
On 04/11/2014 10:31 PM, David Herrmann wrote: > Hi > > On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom > wrote: >> as was discussed a while ago, there are some serious security flaws with >> the current drm master model, that allows a >> user that had previous access or current access to an X server terminal >> to access the GPU memory of the active X server, without being >> authenticated to the X server and thereby also access other user's >> secret information > 1a) and 1b) are moot if you disallow primary-node access but require > clients to use render-nodes with dma-buf. There're no gem-names on > render-nodes so no way to access other buffers (assuming the GPU does > command-stream checking and/or VM). Disallowing primary node access will break older user-space drivers and non-root EGL clients. I'm not sure that's OK, even if the change is done from user-space. A simple gem fix would also do the trick. > > 2) There is no DRM-generic data other than buffers that is global. So > imho this is a driver-specific issue. > > So I cannot see why this is a DRM issue. The only leaks I see are > legacy interfaces and driver-specific interfaces. The first can be > disabled via chmod() for clients, and the second is something driver > authors should fix. Yeah, but some driver authors can't or won't fix the drivers w r t this, hence the security levels. Thanks, /Thomas > > Thanks > David > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v2 00/14] Thunderbolt support for Apple MBP
On Fri, Apr 11, 2014 at 02:24:47AM +0200, Andreas Noever wrote: > Hi > > This is version 2 of my Thunderbolt driver for Apple hardware (see [1] for > v1). > The short story is that Apple decided to implement hotplug support in a driver > instead of the firmware. The firmware will only initialize coldplugged > devices. > Hotplugged devices do not work. > > This series adds support for single device hotplug (no chaining) for the > Cactus > Ridge C4 Thunderbolt controller (device id 0x1547, present on MacBookPro10,1). > As far as I can tell newer generations work quite similar and it should be > possible to add support for more controllers with some work. > > Changes from v1: > - suspend/hibernate support (yeah) > - general cleanups and refactoring > > >From my perspective the driver is working quite well and is ready for merging > (maybe someone can tell me whom I should ask to get a review?). I have taken > some care to not stomp on tunnels setup by the firmware for coldplugged > devices. If this works as intendend then there should be no regressions > (coldplugged devices continue to work and simple hotplugged devices will start > working). In particular the Apple Ethernet adapter works very well (and this > is > probably the most used TB device out there). > > Some notes: > - The patch requires Matthew's acpi_osi fix [2] > - @pci, Bjorn: I hope patch 12 is acceptable. If there is a better way to do >this please let me know. > - Thunderbolt displays: I have a pretty good idea on how they should work, > but >I did not yet write any code to support them. Also judging by the replies I > got for v1 of the patch it seems that there are some graphics driver problems > even with coldplugged tb displays (at least on MBP models with discrete > graphics cards). > - Hibernate gotcha: The amount of available memory reported by the firmware >depends on whether a tb device is connected. This makes Linux refuse to > restore the saved image. This has nothing to do with this driver, but you > might > run into it during testing. Very nice work with all of this, I never thought I would ever see this happen for Linux. Of course, I now can't find my thunderbolt ethernet device around here anymore to test this out, I'll go get another one soon... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] FS: Add generic data flush to fsync
On Fri, 11 Apr 2014 00:45:22 -0700 Christoph Hellwig wrote: > On Fri, Apr 11, 2014 at 06:52:42AM +0200, Fabian Frederick wrote: > > Currently, there's no generic HW flush management support in kernel. > > Only 7 filesystems have their own way to manage the barrier flag. > > > > This patch adds MS_BARRIER in sb_flags and conditionnaly issues the flush > > in generic_file_fsync. > > Please don't add a binary mount option for something thast already is a > text option in many filesystems. We can actually enable/disable cache > flushes at the block device level, so I think this can be > unconditional. Ok, that would mean 'older' filesystems -without barrier flag- to call generic_file_fsync would result in a flush but ext4 without journal also calls it ; maybe with nobarrier and I'm not sure it's the only case. How can I deal with this problem ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/14] dma: edma: Add support for DMA_PAUSE/RESUME operation
On 04/11/2014 11:43 AM, Vinod Koul wrote:
> On Tue, Apr 01, 2014 at 04:06:04PM +0300, Peter Ujfalusi wrote:
>> Pause/Resume can be used by the audio stack when the stream is paused/resumed
>> The edma platform code has support for this and the legacy audio stack used
>> this.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> drivers/dma/edma.c | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>> index 2742867fd1e6..7891378a03f0 100644
>> --- a/drivers/dma/edma.c
>> +++ b/drivers/dma/edma.c
>> @@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
>> return 0;
>> }
>>
>> +static int edma_dma_pause(struct edma_chan *echan)
>> +{
>> +/* Pause/Resume only allowed with cyclic mode */
>> +if (!echan->edesc->cyclic)
>> +return -EINVAL;
> why this artificial restriction? The driver can do pause even for non cyclic
> cases too? Yes the usage is in cyclic context but why should we limit any
> future
> work on this?
>
We struggled with this, and we certainly we don't want pauses in
non-cyclic EDMA... we tried doing a "pause" and it was a disaster as the
events keep coming in and those can't be paused, and EDMA hardware wont
queue them during the pause, it'll just generate an error interrupt storm.
Thanks,
-Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/14] DMA: edma: Use different eventq for cyclic channels
On 04/11/2014 11:47 AM, Vinod Koul wrote: > On Thu, Apr 10, 2014 at 11:36:30AM -0500, Joel Fernandes wrote: >> On 04/01/2014 08:06 AM, Peter Ujfalusi wrote: >>> To improve latency with cyclic DMA operation it is preferred to >>> use different eventq/tc than the default which is used by all >>> other drivers (mmc, spi, i2c, etc). >>> When preparing the cyclic dma ask for non default queue for the >>> channel which is going to be used with cyclic mode. >>> >>> Signed-off-by: Peter Ujfalusi >>> --- >>> drivers/dma/edma.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c >>> index 1dd9e8806975..10048b40fac8 100644 >>> --- a/drivers/dma/edma.c >>> +++ b/drivers/dma/edma.c >>> @@ -628,6 +628,9 @@ static struct dma_async_tx_descriptor >>> *edma_prep_dma_cyclic( >>> edesc->pset[i].opt |= TCINTEN; >>> } >>> >>> + /* Use different eventq/tc for cyclic DMA to reduce latency */ >>> + edma_request_non_default_queue(echan->ch_num); >>> + >>> return vchan_tx_prep(>vchan, >vdesc, tx_flags); >>> } >>> >>> >> >> Is there any way to guarantee that the non-default queue is of the >> highest priority, or in other words default queue is of lowest priority. > well as we are discussing in other thread, it would make sense to pass the > required priority (i am using audio so pls give me highest one) > Yes, I'm aware of that part of the discussion ;) I also replied there. This post was sent much earlier on. thanks, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfs-rdma: Fix for FMR leaks
Hi Allen-
I reviewed and tested your patch. Comments inline below.
On Apr 9, 2014, at 6:40 PM, Allen Andrews wrote:
> Two memory region leaks iwere found during testing:
>
> 1. rpcrdma_buffer_create: While allocating RPCRDMA_FRMR's
> ib_alloc_fast_reg_mr is called and then ib_alloc_fast_reg_page_list is
> called. If ib_alloc_fast_reg_page_list returns an error it bails out of the
> routine dropping the last ib_alloc_fast_reg_mr frmr region creating a memory
> leak. Added code to dereg the last frmr if ib_alloc_fast_reg_page_list fails.
>
> 2. rpcrdma_buffer_destroy: While cleaning up, the routine will only free the
> MR's on the rb_mws list if there are rb_send_bufs present. However, in
> rpcrdma_buffer_create while the rb_mws list is being built if one of the MR
> allocation requests fail after some MR's have been allocated on the rb_mws
> list the routine never gets to create any rb_send_bufs but instead jumps to
> the rpcrdma_buffer_destroy routine which will never free the MR's on rb_mws
> list because the rb_send_bufs were never created. This leaks all the MR's
> on the rb_mws list that were created prior to one of the MR allocations
> failing.
>
> Issue(2) was seen during testing. Our adapter had a finite number of MR's
> available and we created enough connections to where we saw an MR allocation
> failure on our Nth NFS connection request. After the kernel cleaned up the
> resources it had allocated for the Nth connection we noticed that FMR's had
> been leaked due to the coding error described above.
>
> Issue(1) was seen during a code review while debugging issue(2).
>
> Signed-off-by: Allen Andrews
> ---
>
> net/sunrpc/xprtrdma/verbs.c | 79 ---
> 1 files changed, 44 insertions(+), 35 deletions(-)
>
> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c index
> 9372656..54f592d 100644
> --- a/net/sunrpc/xprtrdma/verbs.c
> +++ b/net/sunrpc/xprtrdma/verbs.c
> @@ -1058,6 +1058,14 @@ rpcrdma_buffer_create(struct rpcrdma_buffer *buf,
> struct rpcrdma_ep *ep,
> dprintk("RPC: %s: "
> "ib_alloc_fast_reg_page_list "
> "failed %i\n", __func__, rc);
> +
> + rc = ib_dereg_mr(r->r.frmr.fr_mr);
This clears “rc,” wiping the error returned by ib_alloc_fast_reg_page_list().
Then rpcrdma_buffer_create() returns zero, even though it failed, and xprtrdma
thinks the
transport is set up and ready for use. Panic.
I think you can safely ignore the return code from ib_dereg_mr() here.
> + if (rc)
> + dprintk("RPC: %s:"
> + " ib_dereg_mr"
> + " failed %i\n",
> + __func__, rc);
> +
> goto out;
> }
> list_add(>mw_list, >rb_mws); @@ -1194,41
> +1202,6 @@ rpcrdma_buffer_destroy(struct rpcrdma_buffer *buf)
This line is broken: the “@@“ should start on the next line. Some kind of
e-mail snafu?
> kfree(buf->rb_recv_bufs[i]);
> }
> if (buf->rb_send_bufs && buf->rb_send_bufs[i]) {
> - while (!list_empty(>rb_mws)) {
> - r = list_entry(buf->rb_mws.next,
> - struct rpcrdma_mw, mw_list);
> - list_del(>mw_list);
> - switch (ia->ri_memreg_strategy) {
> - case RPCRDMA_FRMR:
> - rc = ib_dereg_mr(r->r.frmr.fr_mr);
> - if (rc)
> - dprintk("RPC: %s:"
> - " ib_dereg_mr"
> - " failed %i\n",
> - __func__, rc);
> -
> ib_free_fast_reg_page_list(r->r.frmr.fr_pgl);
> - break;
> - case RPCRDMA_MTHCAFMR:
> - rc = ib_dealloc_fmr(r->r.fmr);
> - if (rc)
> - dprintk("RPC: %s:"
> - " ib_dealloc_fmr"
> - " failed %i\n",
> - __func__, rc);
> - break;
> - case RPCRDMA_MEMWINDOWS_ASYNC:
> - case RPCRDMA_MEMWINDOWS:
> - rc = ib_dealloc_mw(r->r.mw);
> -
[PATCH v2 0/2] Initial implementation of Intel MID watchdog driver
Hi, This patch set is an initial implementation of a generic Intel MID watchdog driver. It currently supports Intel Merrifield only, but will extend to other SoCs of MID family. changes from v1 to v2: - Fixed Kconfig entry as per Guenter Roeck suggestion Br, David -- David Cohen (2): watchdog: add Intel MID watchdog driver support x86: intel-mid: add watchdog platform code for Merrifield arch/x86/platform/intel-mid/device_libs/Makefile | 1 + .../platform/intel-mid/device_libs/platform_wdt.c | 43 + drivers/watchdog/Kconfig | 13 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/intel-mid_wdt.c | 209 + 5 files changed, 267 insertions(+) create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_wdt.c create mode 100644 drivers/watchdog/intel-mid_wdt.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] x86: intel-mid: add watchdog platform code for Merrifield
This patch adds platform code for Intel Merrifield.
Since the watchdog is not part of SFI table, we have no other option but
to manually register watchdog's platform device (argh!).
Change-Id: I920968649847577a0aa1ae0b26f2a3551f77d576
Signed-off-by: David Cohen
---
arch/x86/platform/intel-mid/device_libs/Makefile | 1 +
.../platform/intel-mid/device_libs/platform_wdt.c | 43 ++
2 files changed, 44 insertions(+)
create mode 100644 arch/x86/platform/intel-mid/device_libs/platform_wdt.c
diff --git a/arch/x86/platform/intel-mid/device_libs/Makefile
b/arch/x86/platform/intel-mid/device_libs/Makefile
index 097e7a7940d8..af9307f2cc28 100644
--- a/arch/x86/platform/intel-mid/device_libs/Makefile
+++ b/arch/x86/platform/intel-mid/device_libs/Makefile
@@ -20,3 +20,4 @@ obj-$(subst m,y,$(CONFIG_DRM_MEDFIELD)) += platform_tc35876x.o
obj-$(subst m,y,$(CONFIG_SERIAL_MRST_MAX3110)) += platform_max3111.o
# MISC Devices
obj-$(subst m,y,$(CONFIG_KEYBOARD_GPIO)) += platform_gpio_keys.o
+obj-$(subst m,y,$(CONFIG_INTEL_MID_WATCHDOG)) += platform_wdt.o
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_wdt.c
b/arch/x86/platform/intel-mid/device_libs/platform_wdt.c
new file mode 100644
index ..be4fc66fbe1b
--- /dev/null
+++ b/arch/x86/platform/intel-mid/device_libs/platform_wdt.c
@@ -0,0 +1,43 @@
+/*
+ * platform_wdt.c: Watchdog platform library file
+ *
+ * (C) Copyright 2014 Intel Corporation
+ * Author: David Cohen
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include
+#include
+#include
+
+#define EXT_TIMER0_MSI 15
+
+static const struct resource tangier_wdt_res[] = {
+ {
+ .start = EXT_TIMER0_MSI,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device mid_wdt_dev = {
+ .name = "intel_mid_wdt",
+ .id = -1,
+};
+
+static int __init register_mid_wdt(void)
+{
+ if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER) {
+ platform_device_add_resources(_wdt_dev,
+ tangier_wdt_res,
+ ARRAY_SIZE(tangier_wdt_res));
+ return platform_device_register(_wdt_dev);
+ }
+
+ return -ENODEV;
+}
+
+rootfs_initcall(register_mid_wdt);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
