This patch is inpired by the patch for drvdata
"device-core: Ensure drvdata = NULL when no driver is bound"
(sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
Also it fixes all occurences in drivers.
Signed-off-by: Michal Simek
---
This patch has been sent as RFC in this thread.
http://lkml.org/lk
* Linus Torvalds wrote:
> [...]
>
> And your numbers for Ingo's patch:
>
> > After testing Ingo's anon-vma rwlock_t conversion (v2) on a 8 socket,
> > 80 core system with aim7, I am quite surprised about the numbers -
> > considering the lack of queuing in rwlocks. A lot of the tests didn't
Some pl330 have per channel irq and it is necessary
to allocate all of them. Loop over irq assigned for this
device to support these pl330 IPs.
For example this IP is available on Xilinx Zynq platform.
Signed-off-by: Michal Simek
---
Hi Vinod,
this is the patch I told you about it. I have teste
Hello Linus,
please pull
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32.git for-linus
to receive the following AVR32 updates for 3.12
Gabor Juhos (2):
avr32: fix clockevents kernel warning
avr32: cast syscall_return to silence compiler warning
Steven Rostedt (1):
* H. Peter Anvin wrote:
> If the goal is to feed this to the field width in printf, which I would
> think would be the dominant use, then you do have to account for the
> minus sign.
The input here is always a nonzero positive integer.
Anyway, I have no objections against using the more gene
* Andi Kleen wrote:
> > breaks "perf top" on my machine. I just see a gray screen with no text
> > at all. Sometimes the following error messages are printed:
> > *** Error in `perf': invalid fastbin entry (free): 0x029b18c0 ***
> > *** Error in `perf': malloc(): memory corruption (fas
Selecting system clock as the counter source clock by default.
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/vf610-twr.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 1a58678..4257054 100644
--- a/arch/arm/boo
The FTM PWM device can be found on Vybrid VF610 Tower and Layerscape LS-1 SoCs.
Signed-off-by: Xiubo Li
Signed-off-by: Alison Wang
Signed-off-by: Jingchang Lu
Reviewed-by: Sascha Hauer
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-fsl-ftm.c | 442 +
This adds the Document for Freescale FTM PWM driver under
Documentation/devicetree/bindings/pwm/.
Signed-off-by: Xiubo Li
---
.../devicetree/bindings/pwm/pwm-fsl-ftm.txt| 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm
Hello,
This patch series is the Freescale FTM PWM implementation. And there are 8
channels most supported by the FTM PWM. This implementation is only compatible
with device tree definition.
This patch series is based on linux-next and has been tested on Vybrid VF610
Tower board using device tr
This adds devicetree node for VF610, and there are 8 channels supported
by default.
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/vf610.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 67d929c..3c23d92 100644
мочи дамочек ошарашивают
http://sticker.yadro.ru/go?url=http://linksearch.it/229573
Yes, works as well. Just survived twe cycles with s2disk. I'm
surprised someone else did not report this earlier btw... Because it
looks pretty generic (i.e. not specific to a 64bit UP system).
Thanks again!
2013/9/30 Rafael J. Wysocki :
> On Sunday, September 29, 2013 09:22:45 AM Ronald wrote:
>
(2013/09/30 14:08), Namhyung Kim wrote:
> Hi Masami,
>
> Just a nitpick.
>
> On Fri, 27 Sep 2013 15:57:07 +0900, Masami Hiramatsu wrote:
>> /**
>> + * die_find_inlinefunc_next - Search an inlined function at given address
>> + * @cu_die: a CU DIE which including @addr
>
> s/cu_die/sp_die/
>
>
Hi Masami,
Just a nitpick.
On Fri, 27 Sep 2013 15:57:07 +0900, Masami Hiramatsu wrote:
> /**
> + * die_find_inlinefunc_next - Search an inlined function at given address
> + * @cu_die: a CU DIE which including @addr
s/cu_die/sp_die/
And it doesn't look like a CU DIE, anyway.
Thanks,
Namhyung
Hi Linus,
Please pull ARC fixes for 3.12.
Thx,
-Vineet
->
The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983:
Linux 3.12-rc2 (2013-09-23 15:41:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vgupt
On Mon, Sep 30, 2013 at 01:15:02PM +1000, Dave Airlie wrote:
> On Mon, Sep 30, 2013 at 1:06 PM, Matthew Garrett wrote:
> > Likely indicates that our ACPI reboot handling still isn't bug
> > compatible with Windows. We'd do better fixing that than adding more DMI
> > entries.
>
> are these only wi
On 09/29/2013 08:15 PM, Dave Airlie wrote:
>>
>> Likely indicates that our ACPI reboot handling still isn't bug
>> compatible with Windows. We'd do better fixing that than adding more DMI
>> entries.
>
> are these only with VTd enabled? I have some Dells that won't reboot
> with VTd turned on, I r
On Wed, 2013-09-25 at 08:23 -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 25, 2013 at 02:07:58PM +0300, Luca Coelho wrote:
[...]
> > Ah, and I forgot to say that you should update the WHENCE file
> > accordingly too. Check the wl12xx and wl18xx drivers for examples.
>
> I'll send a pull reque
On 09/30/2013 07:35 AM, Rusty Russell wrote:
> Jason Wang writes:
>> We used to use a percpu structure vq_index to record the cpu to queue
>> mapping, this is suboptimal since it duplicates the work of XPS and
>> loses all other XPS functionality such as allowing use to configure
>> their own tran
On Mon, Sep 30, 2013 at 1:06 PM, Matthew Garrett wrote:
> On Sun, Sep 29, 2013 at 07:58:10PM -0700, H. Peter Anvin wrote:
>> On 09/29/2013 07:57 PM, Matthew Garrett wrote:
>> > On Fri, Sep 27, 2013 at 03:16:49PM -0500, H. Peter Anvin wrote:
>> >>
>> >> It really is starting to feel like *ALL* Dell
On Sun, Sep 29, 2013 at 03:52:06PM +0900, Namhyung Kim wrote:
> Hi Jiri,
>
> 2013-09-27 (금), 16:32 +0200, Jiri Olsa:
> > We fail build with NO_DEMANGLE with missing -lbfd externals error.
> > The reason is that we now use bfd code in srcline object:
> > perf tools: Implement addr2line directly u
Hi
On Fri, 27 Sep 2013, Suman Anna wrote:
> Paul,
> The hwmod data patches needs to be merged only after the respective DT
> node patches are merged, without which the hwmod entry will not have a
> base address while enabling and idling (using sysc) the hwmod during
> hwmod initialization.
Hmm,
On Sun, Sep 29, 2013 at 07:58:10PM -0700, H. Peter Anvin wrote:
> On 09/29/2013 07:57 PM, Matthew Garrett wrote:
> > On Fri, Sep 27, 2013 at 03:16:49PM -0500, H. Peter Anvin wrote:
> >>
> >> It really is starting to feel like *ALL* Dell machines need reboot=pci?
> >
> > Now that ACPI is default, I
On 09/29/2013 07:57 PM, Matthew Garrett wrote:
> On Fri, Sep 27, 2013 at 03:16:49PM -0500, H. Peter Anvin wrote:
>>
>> It really is starting to feel like *ALL* Dell machines need reboot=pci?
>
> Now that ACPI is default, I'd be surprised if any of them do.
>
Look at the stream of Dell machines w
On Fri, Sep 27, 2013 at 03:16:49PM -0500, H. Peter Anvin wrote:
>
> It really is starting to feel like *ALL* Dell machines need reboot=pci?
Now that ACPI is default, I'd be surprised if any of them do.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "uns
So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
supports devices resembling the NCM standard, but using it also as a mean
to encapsulate other protocols, as is the case for the Huawei E3131 and
E3251 modem devices.
Some precisations are needed however - and I encourage di
Some drivers implementing NCM-like protocols, may re-use those functions, as is
the case in the huawei_cdc_ncm driver.
Export them via EXPORT_SYMBOL_GPL, in accordance with how other functions have
been exported.
Signed-off-by: Enrico Mioso
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/us
Remove device IDs of NCM-like (but not NCM-conformant) devices, that are
handled by the huawwei_cdc_ncm driver now.
Signed-off-by: Enrico Mioso
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 62686be..31f43f7 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/c
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
heavily inspired by the qmi_wwan/cdc_mbim approach & code model.
Suggested-by: Bjorn Mork
Signed-off-by: Enrico Mioso
create mode 100644
On Sun, 29 Sep 2013 19:03:06 -0700, Olof Johansson wrote:
> Hi,
>
> 2013/9/29 Cho KyongHo :
>
> > Ah, I remember that this is merged.
> > I agreed to merge this patch because iommu driver need to be completely
> > changed.
> > Whenever I change exynos-iommu driver, synchronizing samsung-next and
On 09/29/2013 06:51 PM, Greg Kroah-Hartman wrote:
On Sun, Sep 29, 2013 at 06:28:51PM -0700, Guenter Roeck wrote:
On 09/29/2013 12:27 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.11.3 release.
There are 71 patches in this series, all will be posted as a re
On 09/29/2013 02:55 PM, vaughan wrote:
On 09/23/2013 10:56 PM, Jeff Moyer wrote:
Vaughan Cao writes:
register_blkdev(0, NULL) can result kernel Oops by copying from NULL
in strlcpy(). Fix it by checking NULL pointer at the beginning and
WARN when encountered in unregister_blkdev.
Uhh, so yea
Hi,
2013/9/29 Cho KyongHo :
> Ah, I remember that this is merged.
> I agreed to merge this patch because iommu driver need to be completely
> changed.
> Whenever I change exynos-iommu driver, synchronizing samsung-next and
> iommu-next
> branches is a big challenge.
> Thus I decided to remove d
On Sun, Sep 29, 2013 at 09:40:09PM -0400, Dave Jones wrote:
> On Mon, Sep 30, 2013 at 02:31:08AM +0100, Ben Hutchings wrote:
> > From: Bastian Blank
> >
> > Add a Kconfig variable to set the initial value of the Magic SysRq mask
> > (sysctl: kernel.sysrq).
> >
> > Signed-off-by: Ben Hutchi
On Sun, 29 Sep 2013 20:38:38 -0400, Sean Paul wrote:
> On Sun, Sep 29, 2013 at 8:35 PM, Cho KyongHo wrote:
>
> > On Fri, 27 Sep 2013 14:55:51 -0400, Sean Paul wrote:
> > > On Tue, Dec 25, 2012 at 8:54 PM, Cho KyongHo
> > wrote:
> > > > This removes System MMU initialization from arch/arm/mach-ex
On Sun, Sep 29, 2013 at 06:27:27PM -0700, Guenter Roeck wrote:
> On 09/29/2013 12:26 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.14 release.
> > There are 49 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Sun, Sep 29, 2013 at 06:26:02PM -0700, Guenter Roeck wrote:
> On 09/29/2013 12:26 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.64 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one. If anyone has any i
Jason Wang writes:
> We used to use a percpu structure vq_index to record the cpu to queue
> mapping, this is suboptimal since it duplicates the work of XPS and
> loses all other XPS functionality such as allowing use to configure
> their own transmission steering strategy.
>
> So this patch switc
On Sun, Sep 29, 2013 at 06:28:51PM -0700, Guenter Roeck wrote:
> On 09/29/2013 12:27 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.11.3 release.
> > There are 71 patches in this series, all will be posted as a response
> > to this one. If anyone has any i
On Sun, Sep 29, 2013 at 06:24:52PM -0700, Guenter Roeck wrote:
> On 09/29/2013 12:26 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.0.98 release.
> > There are 17 patches in this series, all will be posted as a response
> > to this one. If anyone has any i
On Mon, Sep 30, 2013 at 02:31:08AM +0100, Ben Hutchings wrote:
> From: Bastian Blank
>
> Add a Kconfig variable to set the initial value of the Magic SysRq mask
> (sysctl: kernel.sysrq).
>
> Signed-off-by: Ben Hutchings
> ---
> This has been in Debian for a while, but should probably be
On 09/30/2013 04:23 AM, Paul E. McKenney wrote:
> On Sun, Sep 29, 2013 at 12:24:52PM +0800, Chen Gang wrote:
>> On 09/27/2013 10:29 AM, Chen Gang wrote:
>>> On 09/27/2013 02:33 AM, Paul E. McKenney wrote:
On Thu, Sep 26, 2013 at 10:57:39AM +0800, Chen Gang wrote:
> On 09/26/2013 04:16 AM,
From: Bastian Blank
Add a Kconfig variable to set the initial value of the Magic SysRq mask
(sysctl: kernel.sysrq).
Signed-off-by: Ben Hutchings
---
This has been in Debian for a while, but should probably be signed-off
by Bastian as well.
Debian sets this to 0x01b6, which excludes.
On 09/29/2013 12:27 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.11.3 release.
There are 71 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 ma
On 09/29/2013 12:26 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.10.14 release.
There are 49 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 m
On 09/29/2013 12:26 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.4.64 release.
There are 22 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 ma
On 09/29/2013 12:26 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.0.98 release.
There are 17 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 ma
On Fri, 27 Sep 2013, Javier Martinez Canillas wrote:
> I cc'ed Aaro Koskinen and Paul Walmsley now which seems to have OMAP1
> platforms
> to test. Could you please test [1] and [2] on a OMAP1 board? These patches
> solves a long standing issue we have on OMAP2+ when booting with DT and it
> wou
On Sat, Sep 28, 2013 at 11:55 AM, Linus Torvalds
wrote:
> Btw, I really hate that thing. I think we should turn it back into a
> spinlock. None of what it protects needs a mutex or an rwsem.
>
> Because you guys talk about the regression of turning it into a rwsem,
> but nobody talks about the *or
On 09/29/2013 08:56 PM, Ryan Mallon wrote:
> Okay, this was just the simplest solution I could come up with that
> fixed the issue for me. Is that a tentative acked/reviewed-by? :-).
>
> ~Ryan
I'm interested to see if anyone else has alternative ideas, but for now:
Reviewed-by: Dan Rosenberg
--
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
Acked-by: Pawel Moll
---
drivers/regulator/vexpress.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/regulator/vexpress.c b/drivers/regulator/vexpress.c
index 4668c7f..f3ae28
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
Acked-by: Nishanth Menon
---
drivers/regulator/twl-regulator.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
i
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
Reviewed-by: Axel Lin
---
drivers/regulator/tps6524x-regulator.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
Acked-by: Linus Walleij
---
drivers/regulator/tps6105x-regulator.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/tps61
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/pcap-regulator.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/pcap-regulator.c
b/drivers/regula
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/pcf50633-regulator.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/pcf50633-regulator.c
b/driver
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/max8925-regulator.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/regulator/max8925-regulator.c
b/drivers/re
On 30/09/13 10:41, Dan Rosenberg wrote:
> On 09/29/2013 07:41 PM, George Spelvin wrote:
>>> Right, so the pppd application is actually doing the correct thing.
>> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
>> immediate security hole than leaking kernel addresses. After al
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/lp8788-buck.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/regulator/lp8788-buck.c b/drivers/regulator/lp878
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/lp8788-ldo.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regu
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/lp872x.c | 33 +++--
1 file changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/reg
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/da9210-regulator.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/regulator/da9210-regulator.c
b/drivers/regulat
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
---
drivers/regulator/da9063-regulator.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/regulator/da9063-regulator.c
b/drivers/regulator/da9063-regulator.
Use devm_regulator_register() to make cleanup paths simpler,
and remove unnecessary remove().
Signed-off-by: Jingoo Han
---
drivers/regulator/ab8500-ext.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/re
On Sun, Sep 29, 2013 at 5:40 PM, Davidlohr Bueso wrote:
>
> Hmm, I'm getting the following at bootup:
>
> May be due to missing lock nesting notation
Yes it is. And that reminds me of a problem I think we had with this
code: we had a possible case of the preemption counter nesting too
deeply. I
Use devm_regulator_register() to make cleanup paths simpler.
Signed-off-by: Jingoo Han
Acked-by: Linus Walleij
---
drivers/regulator/ab3100.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index 7d5eaa8..77b46d0 1
On Thursday, September 26, 2013 5:23 PM, Axel Lin wrote:
>
> > Hi Axel,
> >
> > I really appreciate your comment.
> >
> > Then, you mean the following.
> > If I am wrong, please let me know. :-)
> > Thank you.
>
> Then you can remove pmic_remove() function,like below diff.
> With these change, yo
On 09/29/2013 07:41 PM, George Spelvin wrote:
>> Right, so the pppd application is actually doing the correct thing.
> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
> immediate security hole than leaking kernel addresses. After all
> kptr_restrict is optional precisely becau
On Sun, 2013-09-29 at 16:26 -0700, Linus Torvalds wrote:
> On Sun, Sep 29, 2013 at 4:06 PM, Davidlohr Bueso wrote:
> >>
> >> Btw, I really hate that thing. I think we should turn it back into a
> >> spinlock. None of what it protects needs a mutex or an rwsem.
> >
> > The same should apply to i_mm
On Fri, 27 Sep 2013 14:55:51 -0400, Sean Paul wrote:
> On Tue, Dec 25, 2012 at 8:54 PM, Cho KyongHo wrote:
> > This removes System MMU initialization from arch/arm/mach-exynos/
> > to move them to DT and the exynos-iommu driver except gating clock
> > definitions.
> >
>
>
> exynos with iommu sup
On Sunday, September 29, 2013 09:22:45 AM Ronald wrote:
> Attached patch fixes the issue. Both methods function as they did
> before. Thanks for the superfast fix!
You're welcome, it's not the final one, however.
Can you please test the one below and report back?
Rafael
---
kernel/power/snaps
This is only needed for 3.11, as s390 has now been changed to use the
generic IRQ code upstream.
These functions are currently defined only if CONFIG_GENERIC_HARDIRQS
is enabled. But they are still needed on s390 which has its own IRQ
management.
References:
https://buildd.debian.org/status/fet
Hi Linus,
Please pull these bugfixes for the Apparmor code, for regressions
introduced in the 3.12 pull request.
The following changes since commit 15c03dd4859ab16f9212238f29dd315654aa94f6:
Linux 3.12-rc3 (2013-09-29 15:02:38 -0700)
are available in the git repository at:
git://git.kernel.
On Mon, Sep 30, 2013 at 12:07:11AM +0100, Ben Hutchings wrote:
> On Tue, 2013-09-24 at 17:18 -0700, Greg Kroah-Hartman wrote:
> > 3.11-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Jan Kara
> >
> > commit 5f1132b2b
> Right, so the pppd application is actually doing the correct thing.
And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
immediate security hole than leaking kernel addresses. After all
kptr_restrict is optional precisely because the benefit is marginal.
The interesting questio
On 09/28/2013 11:34 PM, Charles Keepax wrote:
> In the case of a device tree system there will be no pdata attached to
> the device, causing us to deference a NULL pointer. Better to take the
> pdata from the Arizona structure as this will always exist and we know
> will have been populated since i
On 30/09/13 09:15, George Spelvin wrote:
> The basic idea is good, but I'm not sure if this is the correct permission
> check to use.
>
> After all, a setuid program might also want to give filtered access to
> a /proc file with some %pK values.
Yeah. I'm not sure if this will break some applicat
On Sun, Sep 29, 2013 at 4:06 PM, Davidlohr Bueso wrote:
>>
>> Btw, I really hate that thing. I think we should turn it back into a
>> spinlock. None of what it protects needs a mutex or an rwsem.
>
> The same should apply to i_mmap_mutex, having a similar responsibility
> to the anon-vma lock with
The basic idea is good, but I'm not sure if this is the correct permission
check to use.
After all, a setuid program might also want to give filtered access to
a /proc file with some %pK values.
The fundamental problem is that %pK is using permissions at the time
of the read(), while the general
On Tue, 2013-09-24 at 17:18 -0700, Greg Kroah-Hartman wrote:
> 3.11-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Jan Kara
>
> commit 5f1132b2ba8c873f25982cf45917e8455fb6c962 upstream.
[...]
Is this needed for any older kernel versions
On Sat, 2013-09-28 at 11:55 -0700, Linus Torvalds wrote:
> On Sat, Sep 28, 2013 at 12:41 AM, Ingo Molnar wrote:
> >
> >
> > Yeah, I fully agree. The reason I'm still very sympathetic to Tim's
> > efforts is that they address a regression caused by a mechanic
> > mutex->rwsem conversion:
> >
> >
I'm back to a Sunday release schedule, so here it is, rc3.
Nothing really special stands out. There's a fair amount of churn in
mm, which is unusual at this point, but that's all reverts: during the
merge window Andrew sent some changes that were still being discussed,
and we're reverting them for
On Sun, Sep 29, 2013 at 03:46:33PM -0700, Linus Torvalds wrote:
> On Sun, Sep 29, 2013 at 3:41 PM, Theodore Ts'o wrote:
> > On Sat, Sep 28, 2013 at 01:13:07PM -0700, Yinghai Lu wrote:
> >> Fixed by add checking in pci_enable_bridge, and call pci_set_master
> >> if driver skip that.
> >> That will
On 2013.09.29 at 14:33 -0700, Andi Kleen wrote:
> > breaks "perf top" on my machine. I just see a gray screen with no text
> > at all. Sometimes the following error messages are printed:
> > *** Error in `perf': invalid fastbin entry (free): 0x029b18c0 ***
> > *** Error in `perf': malloc(
On Sun, Sep 29, 2013 at 3:41 PM, Theodore Ts'o wrote:
> On Sat, Sep 28, 2013 at 01:13:07PM -0700, Yinghai Lu wrote:
>> Fixed by add checking in pci_enable_bridge, and call pci_set_master
>> if driver skip that.
>> That will make the code more robot and wade off problem for missing
>> pci_set_maste
On Sat, Sep 28, 2013 at 01:13:07PM -0700, Yinghai Lu wrote:
> Fixed by add checking in pci_enable_bridge, and call pci_set_master
> if driver skip that.
> That will make the code more robot and wade off problem for missing
> pci_set_master in drivers.
Petty spelling nit; feel free to ignore unless
Some setuid binaries will allow reading of files which have read permission by
the real user id. This is problematic with files which use %pK because the
contents of the file is different when opened as root, and displaying the
contents may leak kernel pointer values.
This happens for examp
On Sun, Sep 29, 2013 at 06:37:50PM +0900, Namhyung Kim wrote:
> The file->f_op check in do_readv_writev() is redundant since all of
> its caller (vfs_readv and vfs_writev) already did the check. The
> same goes to compat_do_readv_writev().
... and the right fix is to kill all those checks complet
From: Vincent Li
Date: Tue, 24 Sep 2013 14:09:48 -0700
> the reason for this patch is that we have a multi blade cluster platform
> sharing 'floating management ip' and also that each blade has its own
> management ip on the management interface, so whichever blade in the
> cluster becomes prim
On Sun, 29 Sep 2013 20:36:34 +0200
Oleg Nesterov wrote:
> Why? Say, percpu_rw_semaphore, or upcoming changes in get_online_cpus(),
> (Peter, I think they should be unified anyway, but lets ignore this for
> now). Or freeze_super() (which currently looks buggy), perhaps something
> else. This pa
> breaks "perf top" on my machine. I just see a gray screen with no text
> at all. Sometimes the following error messages are printed:
> *** Error in `perf': invalid fastbin entry (free): 0x029b18c0 ***
> *** Error in `perf': malloc(): memory corruption (fast): 0x00ee0b10
> ***
Based upon how quickly you sent these two patches, the first of which
wouldn't even compile, I have zero confidence that you actually
booted and tested this patch at all.
I'm not applying this until you take the time to boot and test the
change in some way, and say explicitly in your commit messa
On Sun, Sep 29, 2013 at 05:23:37PM -0400, Austin S Hemmelgarn wrote:
> I'm not saying that should just be included without substantiation, I
> simply mean that the reason to include it (as far as I am concerned)
> is that it doesn't break anything and provides something useful that
> isn't in the k
On 09/29/2013 04:50 PM, Borislav Petkov wrote:
> On Sun, Sep 29, 2013 at 04:41:02PM -0400, Austin S Hemmelgarn
> wrote:
>> While I understand that you want decisive proof that it provides
>> an improvement, does it specifically matter if the option is
>> unused by most people and doesn't result in
On Sun, Sep 29, 2013 at 04:41:02PM -0400, Austin S Hemmelgarn wrote:
> While I understand that you want decisive proof that it provides an
> improvement, does it specifically matter if the option is unused by
> most people and doesn't result in a negative performance hit when
> used?
Just having t
On 09/29/2013 02:01 PM, Borislav Petkov wrote:
> On Sun, Sep 29, 2013 at 01:54:00PM -0400, Austin S Hemmelgarn
> wrote:
>> From: Austin S. Hemmelgarn
>>
>> This patch adds Kconfig options to allow optimization for AMD
>> family 10h, AMD Bulldozer, and AMD Piledriver derived CPU's in
>> version 3.
From: Tomas Winkler
fixmem32 is assigned to address of res->data member
so the address is always valid
Actually since we are not checking for res != NULL
static analyzing is complaining about referencing the pointer
and consequent check for null.
The code snippet looks confusing also for human e
From: Prarit Bhargava
The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
registers to userspace. The Kconfig help points out that in some cases this
can be a security risk as some systems may erroneously configure the map such
that additional data is exposed to userspace.
Th
On Sun, Sep 29, 2013 at 12:24:52PM +0800, Chen Gang wrote:
> On 09/27/2013 10:29 AM, Chen Gang wrote:
> > On 09/27/2013 02:33 AM, Paul E. McKenney wrote:
> >> On Thu, Sep 26, 2013 at 10:57:39AM +0800, Chen Gang wrote:
> >>> On 09/26/2013 04:16 AM, Paul E. McKenney wrote:
> On Wed, Sep 25, 2013
1 - 100 of 343 matches
Mail list logo
