Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
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:
>> 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/snapshot.c |5 -
> kernel/power/user.c |8
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> Index: linux-pm/kernel/power/snapshot.c
> ===
> --- linux-pm.orig/kernel/power/snapshot.c
> +++ linux-pm/kernel/power/snapshot.c
> @@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void)
> struct memory_bitmap *bm1, *bm2;
> int error = 0;
>
> - BUG_ON(forbidden_pages_map || free_pages_map);
> + if (forbidden_pages_map && free_pages_map)
> + return 0;
> + else
> + BUG_ON(forbidden_pages_map || free_pages_map);
>
> bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
> if (!bm1)
> Index: linux-pm/kernel/power/user.c
> ===
> --- linux-pm.orig/kernel/power/user.c
> +++ linux-pm/kernel/power/user.c
> @@ -39,6 +39,7 @@ static struct snapshot_data {
> char frozen;
> char ready;
> char platform_support;
> + bool free_bitmaps;
> } snapshot_state;
>
> atomic_t snapshot_device_available = ATOMIC_INIT(1);
> @@ -82,6 +83,10 @@ static int snapshot_open(struct inode *i
> data->swap = -1;
> data->mode = O_WRONLY;
> error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
> + if (!error) {
> + error = create_basic_memory_bitmaps();
> + data->free_bitmaps = !error;
> + }
> if (error)
> pm_notifier_call_chain(PM_POST_RESTORE);
> }
> @@ -111,6 +116,8 @@ static int snapshot_release(struct inode
> pm_restore_gfp_mask();
> free_basic_memory_bitmaps();
> thaw_processes();
> + } else if (data->free_bitmaps) {
> + free_basic_memory_bitmaps();
> }
> pm_notifier_call_chain(data->mode == O_RDONLY ?
> PM_POST_HIBERNATION : PM_POST_RESTORE);
> @@ -231,6 +238,7 @@ static long snapshot_ioctl(struct file *
> break;
> pm_restore_gfp_mask();
> free_basic_memory_bitmaps();
> + data->free_bitmaps = false;
> thaw_processes();
> data->frozen = 0;
> break;
>
--
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: Re: [PATCH -tip ] [BUGFIX] perf probe: Fix to find line information for probe list
(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/
>
> And it doesn't look like a CU DIE, anyway.
Oops, right!
Thank you for review :)
>
>
> Thanks,
> Namhyung
>
>
>> + * @addr: target address
>> + * @die_mem: a buffer for result DIE
>> + *
>> + * Search an inlined function DIE which includes @addr. Stores the
>> + * DIE to @die_mem and returns it if found. Returns NULL if failed.
>> + * Even if several inlined functions are expanded recursively, this
>> + * doesn't trace it down, and returns the topmost one.
>> + */
>> +Dwarf_Die *die_find_inlinefunc_next(Dwarf_Die *sp_die, Dwarf_Addr addr,
>> +Dwarf_Die *die_mem)
>> +{
>> +return die_find_child(sp_die, __die_find_inline_cb, , die_mem);
>> +}
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
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 -tip ] [BUGFIX] perf probe: Fix to find line information for probe list
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
> + * @addr: target address
> + * @die_mem: a buffer for result DIE
> + *
> + * Search an inlined function DIE which includes @addr. Stores the
> + * DIE to @die_mem and returns it if found. Returns NULL if failed.
> + * Even if several inlined functions are expanded recursively, this
> + * doesn't trace it down, and returns the topmost one.
> + */
> +Dwarf_Die *die_find_inlinefunc_next(Dwarf_Die *sp_die, Dwarf_Addr addr,
> + Dwarf_Die *die_mem)
> +{
> + return die_find_child(sp_die, __die_find_inline_cb, , die_mem);
> +}
--
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] ARC fixes for 3.12
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/vgupta/arc.git/ tags/arc-fixes-for-3.12 for you to fetch changes up to 55c2e26204276b27f2b7a63123b701c950e45d89: ARC: Use clockevents_config_and_register over clockevents_register_device (2013-09-27 16:28:48 +0530) ARC Fixes for 3.12 * Handling unaligned access in zero delay loops * spinlock livelock fix for SMP systemC model * fixing 32bit overflow in access_ok * better setup of clockevents Mischa Jonker (1): ARC: Handle zero-overhead-loop in unaligned access handler Uwe Kleine-König (1): ARC: Use clockevents_config_and_register over clockevents_register_device Vineet Gupta (2): ARC: Fix 32-bit wrap around in access_ok() ARC: Workaround spinlock livelock in SMP SystemC simulation arch/arc/include/asm/spinlock.h | 9 - arch/arc/include/asm/uaccess.h | 4 ++-- arch/arc/kernel/time.c | 7 ++- arch/arc/kernel/unaligned.c | 6 ++ 4 files changed, 18 insertions(+), 8 deletions(-) -- 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: Fix apparent cut-n-paste mistake in Dell reboot workaround.
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 with VTd enabled? I have some Dells that won't reboot > with VTd turned on, I remember you though it was an acpi bug we > couldn't do much with. Oh, that's true - the ACPI reboot vector on the Dell tables I have to hand appears to be via the keyboard controller, so there's probably some SMM involved. I don't know if the VTd thing is still a problem (David Woodhouse was looking into that at one point), but that would be a reasonable point to start from. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Fix apparent cut-n-paste mistake in Dell reboot workaround.
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 remember you though it was an acpi bug we > couldn't do much with. > It would be very interesting to know what the heck the ACPI reset port is set to in these machines. -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] ti-connectivity: add wl1251 firmware and license
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 request, but how about this ? I don't think we can > change the license. It seems like the other firmwares are using the > older license, I'd argue those should be changed to the new one, but > that's another discussion. [...] I haven't seen this pull request, so it looks like there is nothing for me to apply at the moment. Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part
Re: [PATCH net-next] virtio-net: switch to use XPS to choose txq
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 transmission steering strategy.
>>
>> So this patch switches to use XPS and suggest a default mapping when
>> the number of cpus is equal to the number of queues. With XPS support,
>> there's no need for keeping per-cpu vq_index and .ndo_select_queue(),
>> so they were removed also.
>>
>> Cc: Rusty Russell
>> Cc: Michael S. Tsirkin
>> Signed-off-by: Jason Wang
>> ---
>> drivers/net/virtio_net.c | 55
>> +++--
>> 1 files changed, 9 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index defec2b..4102c1b 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -127,9 +127,6 @@ struct virtnet_info {
>> /* Does the affinity hint is set for virtqueues? */
>> bool affinity_hint_set;
>>
>> -/* Per-cpu variable to show the mapping from CPU to virtqueue */
>> -int __percpu *vq_index;
>> -
>> /* CPU hot plug notifier */
>> struct notifier_block nb;
>> };
>> @@ -1063,7 +1060,6 @@ static int virtnet_vlan_rx_kill_vid(struct net_device
>> *dev,
>> static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
>> {
>> int i;
>> -int cpu;
>>
>> if (vi->affinity_hint_set) {
>> for (i = 0; i < vi->max_queue_pairs; i++) {
>> @@ -1073,20 +1069,11 @@ static void virtnet_clean_affinity(struct
>> virtnet_info *vi, long hcpu)
>>
>> vi->affinity_hint_set = false;
>> }
>> -
>> -i = 0;
>> -for_each_online_cpu(cpu) {
>> -if (cpu == hcpu) {
>> -*per_cpu_ptr(vi->vq_index, cpu) = -1;
>> -} else {
>> -*per_cpu_ptr(vi->vq_index, cpu) =
>> -++i % vi->curr_queue_pairs;
>> -}
>> -}
>> }
>>
>> static void virtnet_set_affinity(struct virtnet_info *vi)
>> {
>> +cpumask_var_t cpumask;
>> int i;
>> int cpu;
>>
>> @@ -1100,15 +1087,21 @@ static void virtnet_set_affinity(struct virtnet_info
>> *vi)
>> return;
>> }
>>
>> +if (!alloc_cpumask_var(, GFP_KERNEL))
>> +return;
>> +
>> i = 0;
>> for_each_online_cpu(cpu) {
>> virtqueue_set_affinity(vi->rq[i].vq, cpu);
>> virtqueue_set_affinity(vi->sq[i].vq, cpu);
>> -*per_cpu_ptr(vi->vq_index, cpu) = i;
>> +cpumask_clear(cpumask);
>> +cpumask_set_cpu(cpu, cpumask);
>> +netif_set_xps_queue(vi->dev, cpumask, i);
>> i++;
>> }
>>
>> vi->affinity_hint_set = true;
>> +free_cpumask_var(cpumask);
>> }
> Um, isn't this just cpumask_of(cpu)?
True, I thought it should be somewhat more easier.
Will post V2.
>
> Cheers,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix apparent cut-n-paste mistake in Dell reboot workaround.
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 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 we're still getting reboot bug >> reports for... > > 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 remember you though it was an acpi bug we couldn't do much with. Dave. -- 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/3] perf tools: Separate lbfd check out of NO_DEMANGLE condition
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 using libbfd > > > > So we need to check/add -lbfd always now. > > > > Signed-off-by: Jiri Olsa > > Cc: Corey Ashford > > Cc: Ingo Molnar > > Cc: Namhyung Kim > > Cc: Paul Mackerras > > Cc: Peter Zijlstra > > Cc: Arnaldo Carvalho de Melo > > Cc: David Ahern > > --- > > tools/perf/config/Makefile | 17 - > > 1 file changed, 8 insertions(+), 9 deletions(-) > > > > diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile > > index 8b49a00..40a41c6 100644 > > --- a/tools/perf/config/Makefile > > +++ b/tools/perf/config/Makefile > > @@ -360,6 +360,13 @@ else > >endif > > endif > > > > +FLAGS_BFD=$(CFLAGS) $(LDFLAGS) $(EXTLIBS) -DPACKAGE='perf' -lbfd > > +has_bfd := $(call try-cc,$(SOURCE_BFD),$(FLAGS_BFD),libbfd) > > +ifeq ($(has_bfd),y) > > + EXTLIBS += -lbfd > > + CFLAGS += -DLIBBFD_SUPPORT > > +endif > > + > > ifdef NO_DEMANGLE > >CFLAGS += -DNO_DEMANGLE > > else > > @@ -367,11 +374,7 @@ else > > EXTLIBS += -liberty > > CFLAGS += -DHAVE_CPLUS_DEMANGLE > >else > > -FLAGS_BFD=$(CFLAGS) $(LDFLAGS) $(EXTLIBS) -DPACKAGE='perf' -lbfd > > -has_bfd := $(call try-cc,$(SOURCE_BFD),$(FLAGS_BFD),libbfd) > > -ifeq ($(has_bfd),y) > > - EXTLIBS += -lbfd > > -else > > +ifneq ($(has_bfd),y) > >FLAGS_BFD_IBERTY=$(FLAGS_BFD) -liberty > >has_bfd_iberty := $(call > > try-cc,$(SOURCE_BFD),$(FLAGS_BFD_IBERTY),liberty) > >ifeq ($(has_bfd_iberty),y) > > @@ -397,10 +400,6 @@ else > >endif > > endif > > > > -ifndef ($(filter -lbfd,$(EXTLIBS)),) > > - CFLAGS += -DLIBBFD_SUPPORT > > -endif > > - > > ifndef NO_STRLCPY > >ifeq ($(call try-cc,$(SOURCE_STRLCPY),,-DHAVE_STRLCPY),y) > > CFLAGS += -DHAVE_STRLCPY > > Is it enough to check on -lbfd only? I guess libbfd can have additional > dependencies to libiberty and libz. If so, this patch can fail to set > -DLIBBFD_SUPPORT, right? hum, you're right.. so it's 2 bugs fixed by removing that code ;-) jirka -- 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: [PATCHv2 0/9] omap hwspinlock dt support
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, ideally there shouldn't be a merge dependency here. Could you please send a patch to the hwmod core that logs a warning and skips the operation in these circumstances? Or maybe just skips the registration of the device? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix apparent cut-n-paste mistake in Dell reboot workaround.
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'd be surprised if any of them do. > > > > Look at the stream of Dell machines we're still getting reboot bug > reports for... 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. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Fix apparent cut-n-paste mistake in Dell reboot workaround.
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 we're still getting reboot bug reports for... -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: Fix apparent cut-n-paste mistake in Dell reboot workaround.
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 "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 V5 net-next 0/3] The huawei_cdc_ncm driver
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 discussion on this: and
that's why I'm sending this message with a broader CC.
Merging those patches might change:
- the way Modem Manager interacts with those devices
- some regressions might be possible if there are some unknown firmware
variants around (Franko?)
First of all: I observed the behaviours of two devices.
Huawei E3131: this device doesn't accept NDIS setup requests unless they're
sent via the embedded AT channel exposed by this driver.
So actually we gain funcionality in this case!
The second case, is the Huawei E3251: which works with standard NCM driver,
still exposing an AT embedded channel. Whith this patch set applied, you gain
some funcionality, loosing the ability to catch standard NCM events for now.
The device will work in both ways with no problems, but this has to be
acknowledged and discussed. Might be we can develop this driver further to
change this, when more devices are tested.
We where thinking Huawei changed their interfaces on new devices - but probably
this driver only works around a nice firmware bug present in E3131, which
prevented the modem from being used in NDIS mode.
I think committing this is definitely wortth-while, since it will allow for
more Huawei devices to be used without serial connection. Some devices like the
E3251 also, reports some status information only via the embedded AT channel,
at least in my case.
Note: I'm not subscribed to any list except the Modem Manager's one, so please
CC me, thanks!!
Enrico Mioso (3):
net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
net: cdc_ncm: remove non-standard NCM device IDs
drivers/net/usb/Kconfig | 15 +++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/cdc_ncm.c| 17 +--
drivers/net/usb/huawei_cdc_ncm.c | 228 +++
include/linux/usb/cdc_ncm.h | 3 +
5 files changed, 251 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/usb/huawei_cdc_ncm.c
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 net-next 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
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/usb/cdc_ncm.c
index 43afde8..62686be 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -858,7 +858,7 @@ static void cdc_ncm_txpath_bh(unsigned long param)
}
}
-static struct sk_buff *
+struct sk_buff *
cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
{
struct sk_buff *skb_out;
@@ -885,6 +885,7 @@ error:
return NULL;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_tx_fixup);
/* verify NTB header and return offset of first NDP, or negative error */
int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
@@ -965,7 +966,7 @@ error:
}
EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp16);
-static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
{
struct sk_buff *skb;
struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
@@ -1040,6 +1041,7 @@ err_ndp:
error:
return 0;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_rx_fixup);
static void
cdc_ncm_speed_change(struct cdc_ncm_ctx *ctx,
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index cc25b70..163244b 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -133,3 +133,6 @@ extern void cdc_ncm_unbind(struct usbnet *dev, struct
usb_interface *intf);
extern struct sk_buff *cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct
sk_buff *skb, __le32 sign);
extern int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff
*skb_in);
extern int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset);
+struct sk_buff *
+cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags);
+int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 net-next 3/3] net: cdc_ncm: remove non-standard NCM device IDs
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/cdc_ncm.c
@@ -1236,17 +1236,6 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)_info,
},
- /* Huawei NCM devices disguised as vendor specific */
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
- .driver_info = (unsigned long)_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
- .driver_info = (unsigned long)_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
- .driver_info = (unsigned long)_info,
- },
-
/* Infineon(now Intel) HSPA Modem platform */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
USB_CLASS_COMM,
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 net-next 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
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 drivers/net/usb/huawei_cdc_ncm.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 40db312..85e4a01 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -242,6 +242,21 @@ config USB_NET_CDC_NCM
* ST-Ericsson M343 HSPA Mobile Broadband Modem (reference design)
* Ericsson F5521gw Mobile Broadband Module
+config USB_NET_HUAWEI_CDC_NCM
+ tristate "Huawei NCM embedded AT channel support"
+ depends on USB_USBNET
+ select USB_WDM
+ select USB_NET_CDC_NCM
+ help
+ This driver supports huawei-style NCM devices, that use NCM as a
+ transport for other protocols, usually an embedded AT channel.
+ Good examples are:
+ * Huawei E3131
+ * Huawei E3251
+
+ To compile this driver as a module, choose M here: the module
will be
+ called huawei_cdc_ncm.ko.
+
config USB_NET_CDC_MBIM
tristate "CDC MBIM support"
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 8b342cf..b17b5e8 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_USB_IPHETH) += ipheth.o
obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
obj-$(CONFIG_USB_NET_CDC_NCM) += cdc_ncm.o
+obj-$(CONFIG_USB_NET_HUAWEI_CDC_NCM) += huawei_cdc_ncm.o
obj-$(CONFIG_USB_VL600)+= lg-vl600.o
obj-$(CONFIG_USB_NET_QMI_WWAN) += qmi_wwan.o
obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c
new file mode 100644
index 000..ff07b18
--- /dev/null
+++ b/drivers/net/usb/huawei_cdc_ncm.c
@@ -0,0 +1,228 @@
+/* huawei_cdc_ncm.c - handles Huawei devices using the CDC NCM protocol as
+ * transport layer.
+ * Copyright (C) 2013 Enrico Mioso
+ *
+ *
+ * ABSTRACT:
+ * This driver handles devices resembling the CDC NCM standard, but
+ * encapsulating another protocol inside it. An example are some Huawei 3G
+ * devices, exposing an embedded AT channel where you can set up the NCM
+ * connection.
+ * This code has been heavily inspired by the cdc_mbim.c driver, which is
+ * Copyright (c) 2012 Smith Micro Software, Inc.
+ * Copyright (c) 2012 Bjørn Mork
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Driver data */
+struct huawei_cdc_ncm_state {
+ struct cdc_ncm_ctx *ctx;
+ atomic_t pmcount;
+ struct usb_driver *subdriver;
+ struct usb_interface *control;
+ struct usb_interface *data;
+};
+
+static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
+{
+ struct huawei_cdc_ncm_state *drvstate = (void *)_dev->data;
+ int rv = 0;
+
+ if ((on && atomic_add_return(1, >pmcount) == 1) ||
+ (!on && atomic_dec_and_test(>pmcount))) {
+ rv = usb_autopm_get_interface(usbnet_dev->intf);
+ if (rv < 0)
+ goto err;
+ usbnet_dev->intf->needs_remote_wakeup = on;
+ usb_autopm_put_interface(usbnet_dev->intf);
+ }
+err:
+ return rv;
+}
+
+static int huawei_cdc_ncm_wdm_manage_power(struct usb_interface *intf, int
status)
+{
+ struct usbnet *usbnet_dev = usb_get_intfdata(intf);
+
+ /* can be called while disconnecting */
+ if (!usbnet_dev)
+ return 0;
+
+ return huawei_cdc_ncm_manage_power(usbnet_dev, status);
+}
+
+
+static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev, struct usb_interface
*intf)
+{
+ struct cdc_ncm_ctx *ctx;
+ struct usb_driver *subdriver = ERR_PTR(-ENODEV);
+ int ret = -ENODEV;
+ struct huawei_cdc_ncm_state *drvstate = (void *)_dev->data;
+
+ /* altsetting should always be 1 for NCM devices - so we hard-coded
+* it here
+*/
+ ret = cdc_ncm_bind_common(usbnet_dev, intf, 1);
+ if (ret)
+ goto err;
+
+ ctx = drvstate->ctx;
+
+ if (usbnet_dev->status)
+ /* CDC-WMC r1.1 requires wMaxCommand to be "at least 256
+* decimal (0x100)"
+*/
+ subdriver = usb_cdc_wdm_register(ctx->control,
+_dev->status->desc,
+256, /* wMaxCommand */
+
Re: [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
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 > > iommu-next > > branches is a big challenge. > > Thus I decided to remove dependencies to samsung-next branch. > > But I didn't know that the rest of the new driver is not merged soon. :( > > I am sorry about that. > > > > new patch (v10) will be posted soon. > > Will the v10 patch set be incremental based on v6? > The single patch 07/12 is merged to mainline from v6 patches. v10 patch is more advanced than v6. Of course, much more is changed. You can refer the v9 patch what is changed since v6. > How have you tested v10 on mainline? > I just test if the System MMU is correctly enabled and disabled, if page table is correctly maintained. It is done with IOMMU API call from custom driver/device and applications. The test does not involve working with master IPs such as MFC, FIMC and so on. > Thanks, > > -Olof -- 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: [ 00/71] 3.11.3-stable review
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 response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Oct 1 19:26:27 UTC 2013. 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.11.3-rc1.gz and the diffstat can be found below. Build test results: total: 110 pass: 108 skipped: 2 fail: 0 Same as with 3.11.2. Thanks for testing. Any chance we can ever get those two skipped ones fixed. It feels odd that 3.10 passes those and 3.11 doesn't Maybe I should just not report those. "Skipped" means that the configuration no longer exists (or that it does not yet exist). 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 v2] block: register_blkdev doesn't check name against NULL
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 yeah, this is an exported function, so I could see maybe wanting to do the argument checking. But honestly, if your driver can't even get this right, is there any hope of it actually working? This seems like a pointless patch to me, but ultimately it's up to Jens. Cheers, Jeff p.s. the kerneldoc tells you what to put there: * @name: the name of the new block device as a zero terminated string Thanks for your comment, Jeff. I have the same feeling as you, however, shouldn't kernel do its best to provide the maximum stable working ability? And it's test case 7 of block driver in ltp project - http://sourceforge.net/p/ltp/git/ci/master/tree/testcases/kernel/device-drivers/block/kernel_space/test_block.c. It seems their attitude is we should check this. I checked most of the callers of this function in current code tree. Indeed, mostly they pass a static string as a parameter. As jeff has said if a driver wants to get things right, it should able to give right parameters. But as an acknowledge of kernel code protocol, I have a query/question of the similar situation. if a function is a public one and called rather commonly. In what cases should we have a parameter checking in it? I think if the parameter is a rather obvious one that even a look at it in the caller telling OK or not. These parameters may not need checking. thanks chai wen Vaughan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
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 dependencies to samsung-next branch. > But I didn't know that the rest of the new driver is not merged soon. :( > I am sorry about that. > > new patch (v10) will be posted soon. Will the v10 patch set be incremental based on v6? How have you tested v10 on mainline? Thanks, -Olof -- 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] sysrq: Allow access to sensitive keys to be restricted by default
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 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. > > > > 8 - enable debugging dumps of processes etc. > > 64 - enable signalling of processes (term, kill, oom-kill) > > ... > > > > +config MAGIC_SYSRQ_DEFAULT_MASK > > + hex "Default mask for Magic SysRq keys on the console" > > + depends on MAGIC_SYSRQ > > + default 1 > > + help > > +Specifies the default mask for the allowed SysRq keys. This can be > > +used to disable several sensitive keys by default. > > Might be nice to have the mask values duplicated here to save having to > go grepping through code ? Yeah, a hit would be good. Like what '1' does as default would be a nice start :) 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 v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
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-exynos/
> > > > to move them to DT and the exynos-iommu driver except gating clock
> > > > definitions.
> > > >
> > >
> > >
> > > exynos with iommu support no longer compiles with this patch:
> > >
> > > CC drivers/iommu/exynos-iommu.o
> > >
> > /mnt/host/source/src/third_party/kernel-next/drivers/iommu/exynos-iommu.c:32:25:
> > > fatal error: mach/sysmmu.h: No such file or directory
> > > compilation terminated.
> > > make[3]: *** [drivers/iommu/exynos-iommu.o] Error 1
> > >
> >
> > It is my fault.
> > I think you need to apply all v6 patches to compile correctly.
> >
> > Since v8 patches, I checked that every patch is compiled successfully.
> >
> >
> I'm sorry I don't think I explained properly.
>
> This patch has been merged to mainline without the rest of the series. As
> such, mainline with exynos iommu does not currently compile.
>
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 dependencies to samsung-next branch.
But I didn't know that the rest of the new driver is not merged soon. :(
I am sorry about that.
new patch (v10) will be posted soon.
Thank you.
> Sean
>
>
>
>
> > iommu/exynos: do not include removed header
> > patch from v7 patch removes including 'mach/sysmmu.h'.
> >
> > Thank you.
> >
> >
> > > Sean
> > >
> > >
> > > > Signed-off-by: KyongHo Cho
> > > > ---
> > > > arch/arm/mach-exynos/Kconfig | 5 -
> > > > arch/arm/mach-exynos/Makefile | 1 -
> > > > arch/arm/mach-exynos/clock-exynos4.c | 41 +++--
> > > > arch/arm/mach-exynos/clock-exynos4210.c| 9 +-
> > > > arch/arm/mach-exynos/clock-exynos4212.c| 23 ++-
> > > > arch/arm/mach-exynos/clock-exynos5.c | 62 ---
> > > > arch/arm/mach-exynos/dev-sysmmu.c | 274
> > -
> > > > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 ---
> > > > arch/arm/mach-exynos/mach-exynos4-dt.c | 34
> > > > arch/arm/mach-exynos/mach-exynos5-dt.c | 30
> > > > 10 files changed, 137 insertions(+), 408 deletions(-)
> > > > delete mode 100644 arch/arm/mach-exynos/dev-sysmmu.c
> > > > delete mode 100644 arch/arm/mach-exynos/include/mach/sysmmu.h
> > > >
> > > > diff --git a/arch/arm/mach-exynos/Kconfig
> > b/arch/arm/mach-exynos/Kconfig
> > > > index 91d5b6f..eba6eb5 100644
> > > > --- a/arch/arm/mach-exynos/Kconfig
> > > > +++ b/arch/arm/mach-exynos/Kconfig
> > > > @@ -103,11 +103,6 @@ config EXYNOS4_SETUP_FIMD0
> > > > help
> > > > Common setup code for FIMD0.
> > > >
> > > > -config EXYNOS_DEV_SYSMMU
> > > > - bool
> > > > - help
> > > > - Common setup code for SYSTEM MMU in EXYNOS platforms
> > > > -
> > > > config EXYNOS4_DEV_USB_OHCI
> > > > bool
> > > > help
> > > > diff --git a/arch/arm/mach-exynos/Makefile
> > b/arch/arm/mach-exynos/Makefile
> > > > index b189881..435757e 100644
> > > > --- a/arch/arm/mach-exynos/Makefile
> > > > +++ b/arch/arm/mach-exynos/Makefile
> > > > @@ -52,7 +52,6 @@ obj-$(CONFIG_ARCH_EXYNOS4)+= dev-audio.o
> > > > obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
> > > > obj-$(CONFIG_EXYNOS_DEV_DMA) += dma.o
> > > > obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o
> > > > -obj-$(CONFIG_EXYNOS_DEV_SYSMMU)+= dev-sysmmu.o
> > > >
> > > > obj-$(CONFIG_ARCH_EXYNOS) += setup-i2c0.o
> > > > obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
> > > > diff --git a/arch/arm/mach-exynos/clock-exynos4.c
> > b/arch/arm/mach-exynos/clock-exynos4.c
> > > > index bbcb3de..8a8468d 100644
> > > > --- a/arch/arm/mach-exynos/clock-exynos4.c
> > > > +++ b/arch/arm/mach-exynos/clock-exynos4.c
> > > > @@ -24,7 +24,6 @@
> > > >
> > > > #include
> > > > #include
> > > > -#include
> > > >
> > > > #include "common.h"
> > > > #include "clock-exynos4.h"
> > > > @@ -709,53 +708,53 @@ static struct clk exynos4_init_clocks_off[] = {
> > > > .enable = exynos4_clk_ip_peril_ctrl,
> > > > .ctrlbit= (1 << 14),
> > > > }, {
> > > > - .name = SYSMMU_CLOCK_NAME,
> > > > - .devname= SYSMMU_CLOCK_DEVNAME(mfc_l, 0),
> > > > + .name = "sysmmu",
> > > > + .devname= "exynos-sysmmu.0",
> > > > .enable = exynos4_clk_ip_mfc_ctrl,
> > > > .ctrlbit= (1 << 1),
> > > > }, {
> > > > - .name =
Re: [ 00/49] 3.10.14-stable review
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 issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Oct 1 19:15:49 UTC 2013. > > 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.14-rc1.gz > > and the diffstat can be found below. > > > > Build test results: > total: 110 pass: 110 > > Same as with 3.10.13. Yeah! 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: [ 00/22] 3.4.64-stable review
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 issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Oct 1 19:11:47 UTC 2013. > > 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.64-rc1.gz > > and the diffstat can be found below. > > > > Build test results: > total: 103 pass: 89 skipped: 10 fail: 4 > > qemu: > microblaze, mips, mips64, ppc, sh, sparc, x86, x86_64 pass. > arm, sparc64 skipped > > Same results as with 3.4.63. Nice, thanks for testing 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 net-next] virtio-net: switch to use XPS to choose txq
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 switches to use XPS and suggest a default mapping when
> the number of cpus is equal to the number of queues. With XPS support,
> there's no need for keeping per-cpu vq_index and .ndo_select_queue(),
> so they were removed also.
>
> Cc: Rusty Russell
> Cc: Michael S. Tsirkin
> Signed-off-by: Jason Wang
> ---
> drivers/net/virtio_net.c | 55 +++--
> 1 files changed, 9 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index defec2b..4102c1b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -127,9 +127,6 @@ struct virtnet_info {
> /* Does the affinity hint is set for virtqueues? */
> bool affinity_hint_set;
>
> - /* Per-cpu variable to show the mapping from CPU to virtqueue */
> - int __percpu *vq_index;
> -
> /* CPU hot plug notifier */
> struct notifier_block nb;
> };
> @@ -1063,7 +1060,6 @@ static int virtnet_vlan_rx_kill_vid(struct net_device
> *dev,
> static void virtnet_clean_affinity(struct virtnet_info *vi, long hcpu)
> {
> int i;
> - int cpu;
>
> if (vi->affinity_hint_set) {
> for (i = 0; i < vi->max_queue_pairs; i++) {
> @@ -1073,20 +1069,11 @@ static void virtnet_clean_affinity(struct
> virtnet_info *vi, long hcpu)
>
> vi->affinity_hint_set = false;
> }
> -
> - i = 0;
> - for_each_online_cpu(cpu) {
> - if (cpu == hcpu) {
> - *per_cpu_ptr(vi->vq_index, cpu) = -1;
> - } else {
> - *per_cpu_ptr(vi->vq_index, cpu) =
> - ++i % vi->curr_queue_pairs;
> - }
> - }
> }
>
> static void virtnet_set_affinity(struct virtnet_info *vi)
> {
> + cpumask_var_t cpumask;
> int i;
> int cpu;
>
> @@ -1100,15 +1087,21 @@ static void virtnet_set_affinity(struct virtnet_info
> *vi)
> return;
> }
>
> + if (!alloc_cpumask_var(, GFP_KERNEL))
> + return;
> +
> i = 0;
> for_each_online_cpu(cpu) {
> virtqueue_set_affinity(vi->rq[i].vq, cpu);
> virtqueue_set_affinity(vi->sq[i].vq, cpu);
> - *per_cpu_ptr(vi->vq_index, cpu) = i;
> + cpumask_clear(cpumask);
> + cpumask_set_cpu(cpu, cpumask);
> + netif_set_xps_queue(vi->dev, cpumask, i);
> i++;
> }
>
> vi->affinity_hint_set = true;
> + free_cpumask_var(cpumask);
> }
Um, isn't this just cpumask_of(cpu)?
Cheers,
Rusty.
--
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: [ 00/71] 3.11.3-stable review
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 issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Oct 1 19:26:27 UTC 2013. > > 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.11.3-rc1.gz > > and the diffstat can be found below. > > > > Build test results: > total: 110 pass: 108 skipped: 2 fail: 0 > > Same as with 3.11.2. Thanks for testing. Any chance we can ever get those two skipped ones fixed. It feels odd that 3.10 passes those and 3.11 doesn't 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: [ 00/17] 3.0.98-stable review
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 issues with these being applied, please > > let me know. > > > > Responses should be made by Tue Oct 1 19:07:47 UTC 2013. > > 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.0.98-rc1.gz > > and the diffstat can be found below. > > > > > Build test results: > total: 98 pass: 71 skipped: 16 fail: 11 > > qemu: > ppc, sh, sparc, x86, x86_64 passed > arm, microblaze, mips, mips64, sparc64 skipped > > Same results as with 3.0.97. Nice, thanks for testing 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] sysrq: Allow access to sensitive keys to be restricted by default
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 signed-off > by Bastian as well. > > Debian sets this to 0x01b6, which excludes. > > 8 - enable debugging dumps of processes etc. > 64 - enable signalling of processes (term, kill, oom-kill) > ... > > +config MAGIC_SYSRQ_DEFAULT_MASK > +hex "Default mask for Magic SysRq keys on the console" > +depends on MAGIC_SYSRQ > +default 1 > +help > + Specifies the default mask for the allowed SysRq keys. This can be > + used to disable several sensitive keys by default. Might be nice to have the mask values duplicated here to save having to go grepping through code ? Dave -- 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 tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks()
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, Paul E. McKenney wrote: >> On Wed, Sep 25, 2013 at 10:55:30AM +0800, Chen Gang wrote: >>> >>> Thank you for your whole work, firstly :-). >>> >>> And your suggestion about testing (in our discussion) is also valuable >>> to me. >>> >>> I need start LTP in q4. After referenced your suggestion, my first step >>> for using/learning LTP is not mainly for finding kernel issues, but for >>> testing kernel (to improve my kernel testing efficiency). >>> >>> When I want to find issues by reading code, I will consider about LTP >>> too (I will try to find issues which can be tested by LTP). >> >> Doing more testing will be good! You will probably need more tests >> than just LTP, but you must of course start somewhere. > > Give more testing is good, but also mean more time resources cost. If > spend the 'cost', also need get additional 'contributions' (not only > prove an issue), or the 'efficiency' can not be 'acceptable'. > > When "I need more tests than just LTP", firstly I need perform this > test, and then, also try to send "test case" to LTP (I guess, these > kinds of mails are welcomed by LTP). > > And LTP is also a way to find kernel issues, although I will not mainly > depend on it now (but maybe in future), it is better to familiar with it > step by step. > > LTP (Linux Test Project) is one of main kernel mad user at downstream. > Tool chain (GCC/Binutils) is one of kernel main mad tools at upstream. > If we face to the whole kernel, suggest to use them. ;-) Yep, starting with just LTP is OK. But if by this time next year you really should be using more than just LTP. >> >> What I have done is trying to fully use other members contributions, not >> trying to instead of them. >> >> >> And the reason why I want/try to 'open' my 'ideas' to public: >> >> get more suggestions, and completions from other members. >> >> share my ideas, it can let other members provide more contributions (e.g. >> I am glad, if find other members also try 'allmodconfig' on all >> architectures). >> >> If some members replicate me, I will save my current time resources and >> devote them to another things (which also based on other members >> contributions). >> >> >> In my opinion: >> >> "Open and Share" are both important and urgent to everyone, although it >> may not be noticed directly. Like "Air and Water" which God have blessed to >> everyone. > Firstly, thank you very much for your details reply. > In a general sense, of course. > > In many specific cases, effective sharing can require quite a bit of > preparation. For but one example, in Dipankar's and my case, it took > about two years of work (mostly Dipankar's work) to get the initial > implementation of RCU accepted into the Linux kernel. > > In your case, you can invest an average of three days per accepted > patch if you are to achieve your goal of ten patches accepted per month > (if I remember correctly). Of course, not every patch will be accepted, > which reduces your per-patch time. For example, if 50% of your patches > are accepted, you can invest an average of about 1.5 days per patch. > > Of course, investing in learning about test frameworks or specific > kernel subsystems further reduces your time available per patch. > > But if you don't invest in your learning, you will be limited in what > you can effectively contribute. This might be OK, for all I know. > After all, in the 15 million lines of Linux kernel code, there is > probably a very large number of point-problems waiting to be fixed. > > But suppose that you run out of easily found point problems? Or that > you want to do something more wide-ranging than fixes for point problems? > What can you do? > > Here are a few options. If you think more about it, I am sure that you > can come up with others. > > 1.Put the ten-patches-per-month quota aside for a month (or two or > three or whatever is required and appropriate). Spend this time > studying a given kernel subsystem or a given test framework. > (Which kernel subsystem? The best candidates would be those > having bugs but no active maintainer, but which you have the > hardware needed to adequately test.) > > 2.Add a review and/or test component to your monthly quota, so > that a given patch could be substituted for by some number of > Reviewed-by or Tested-by flags. Of course, this gives your > a chicken-and-egg problem because you cannot adequately review > or test without some understanding of the subsystem in
[PATCH] sysrq: Allow access to sensitive keys to be restricted by default
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. 8 - enable debugging dumps of processes etc. 64 - enable signalling of processes (term, kill, oom-kill) Ben. --- a/include/linux/sysrq.h +++ b/include/linux/sysrq.h @@ -18,7 +18,7 @@ #include /* Enable/disable SYSRQ support by default (0==no, 1==yes). */ -#define SYSRQ_DEFAULT_ENABLE 1 +#define SYSRQ_DEFAULT_ENABLE CONFIG_MAGIC_SYSRQ_DEFAULT_MASK /* Possible values of bitmask for enabling sysrq functions */ /* 0x0001 is reserved for enable everything */ --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -312,6 +312,14 @@ config MAGIC_SYSRQ keys are documented in . Don't say Y unless you really know what this hack does. +config MAGIC_SYSRQ_DEFAULT_MASK + hex "Default mask for Magic SysRq keys on the console" + depends on MAGIC_SYSRQ + default 1 + help + Specifies the default mask for the allowed SysRq keys. This can be + used to disable several sensitive keys by default. + config DEBUG_KERNEL bool "Kernel debugging" help -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. -- 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: [ 00/71] 3.11.3-stable review
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 made by Tue Oct 1 19:26:27 UTC 2013. 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.11.3-rc1.gz and the diffstat can be found below. Build test results: total: 110 pass: 108 skipped: 2 fail: 0 Same as with 3.11.2. qemu: arm, microblaze, mips, mips64, ppc, sparc, sparc64, x86, x86_64 pass. sh passed with warning (same as with 3.11.2). 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: [ 00/49] 3.10.14-stable review
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 made by Tue Oct 1 19:15:49 UTC 2013. 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.14-rc1.gz and the diffstat can be found below. Build test results: total: 110 pass: 110 Same as with 3.10.13. qemu: arm, microblaze, mips, mips64, ppc, sparc, sparc64, x86, x86_64 pass. sh passes with warning (same as with 3.10.13). 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: [ 00/22] 3.4.64-stable review
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 made by Tue Oct 1 19:11:47 UTC 2013. 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.64-rc1.gz and the diffstat can be found below. Build test results: total: 103 pass: 89 skipped: 10 fail: 4 qemu: microblaze, mips, mips64, ppc, sh, sparc, x86, x86_64 pass. arm, sparc64 skipped Same results as with 3.4.63. 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: [ 00/17] 3.0.98-stable review
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 made by Tue Oct 1 19:07:47 UTC 2013. 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.0.98-rc1.gz and the diffstat can be found below. Build test results: total: 98 pass: 71 skipped: 16 fail: 11 qemu: ppc, sh, sparc, x86, x86_64 passed arm, microblaze, mips, mips64, sparc64 skipped Same results as with 3.0.97. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
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 > would > be great if you can check that it does not cause regressions on OMAP1 based > boards. Unfortunately my OMAP1 test platform is down at the moment, so am not able to test. But saw that it passed Aaro's tests, so I'd say that's a pretty good endorsement. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rwsem: reduce spinlock contention in wakeup code path
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 *original* regression. > > And it *used* to be a spinlock, and it was changed into a mutex back > in 2011 by commit 2b575eb64f7a. That commit doesn't even have a reason > listed for it, although my dim memory of it is that the reason was > preemption latency. I was wondering about that too. Regarding latencies, we used to have unbounded latencies for anon_vma operations as the AVC chains could get long under some workloads; now that we index the VMAs matching a given anon_vma with an interval tree this particular source of latencies should be gone. So yes, it could be worth trying to go back to a non-sleeping lock. That said, I am very scared of using rwlock_t here, and I would much prefer we choose a fair lock (either spinlock or a new rwlock implementation which guarantees not to starve any locker thread) -- Michel Lespinasse A program is never fully debugged until the last user dies. -- 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] printk: Check real user/group id for %pK
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 -- 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 V4 14/14] regulator: vexpress: use devm_regulator_register()
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..f3ae28a 100644
--- a/drivers/regulator/vexpress.c
+++ b/drivers/regulator/vexpress.c
@@ -96,7 +96,7 @@ static int vexpress_regulator_probe(struct platform_device
*pdev)
config.driver_data = reg;
config.of_node = pdev->dev.of_node;
- reg->regdev = regulator_register(>desc, );
+ reg->regdev = devm_regulator_register(>dev, >desc, );
if (IS_ERR(reg->regdev)) {
err = PTR_ERR(reg->regdev);
goto error_regulator_register;
@@ -119,7 +119,6 @@ static int vexpress_regulator_remove(struct platform_device
*pdev)
struct vexpress_regulator *reg = platform_get_drvdata(pdev);
vexpress_config_func_put(reg->func);
- regulator_unregister(reg->regdev);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 13/14] regulator: twl: use devm_regulator_register()
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
index 78aae4c..8ebd785 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1188,7 +1188,7 @@ static int twlreg_probe(struct platform_device *pdev)
config.driver_data = info;
config.of_node = pdev->dev.of_node;
- rdev = regulator_register(>desc, );
+ rdev = devm_regulator_register(>dev, >desc, );
if (IS_ERR(rdev)) {
dev_err(>dev, "can't register %s, %ld\n",
info->desc.name, PTR_ERR(rdev));
@@ -1217,7 +1217,6 @@ static int twlreg_remove(struct platform_device *pdev)
struct regulator_dev *rdev = platform_get_drvdata(pdev);
struct twlreg_info *info = rdev->reg_data;
- regulator_unregister(rdev);
kfree(info);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 12/14] regulator: tps6524x: use devm_regulator_register()
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/regulator/tps6524x-regulator.c
b/drivers/regulator/tps6524x-regulator.c
index 8b9ee39..9f6bfda 100644
--- a/drivers/regulator/tps6524x-regulator.c
+++ b/drivers/regulator/tps6524x-regulator.c
@@ -577,20 +577,6 @@ static struct regulator_ops regulator_ops = {
.get_current_limit = get_current_limit,
};
-static int pmic_remove(struct spi_device *spi)
-{
- struct tps6524x *hw = spi_get_drvdata(spi);
- int i;
-
- if (!hw)
- return 0;
- for (i = 0; i < N_REGULATORS; i++) {
- regulator_unregister(hw->rdev[i]);
- hw->rdev[i] = NULL;
- }
- return 0;
-}
-
static int pmic_probe(struct spi_device *spi)
{
struct tps6524x *hw;
@@ -598,7 +584,7 @@ static int pmic_probe(struct spi_device *spi)
const struct supply_info *info = supply_info;
struct regulator_init_data *init_data;
struct regulator_config config = { };
- int ret = 0, i;
+ int i;
init_data = dev_get_platdata(dev);
if (!init_data) {
@@ -631,24 +617,17 @@ static int pmic_probe(struct spi_device *spi)
config.init_data = init_data;
config.driver_data = hw;
- hw->rdev[i] = regulator_register(>desc[i], );
- if (IS_ERR(hw->rdev[i])) {
- ret = PTR_ERR(hw->rdev[i]);
- hw->rdev[i] = NULL;
- goto fail;
- }
+ hw->rdev[i] = devm_regulator_register(dev, >desc[i],
+ );
+ if (IS_ERR(hw->rdev[i]))
+ return PTR_ERR(hw->rdev[i]);
}
return 0;
-
-fail:
- pmic_remove(spi);
- return ret;
}
static struct spi_driver pmic_driver = {
.probe = pmic_probe,
- .remove = pmic_remove,
.driver = {
.name = "tps6524x",
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 11/14] regulator: tps6105x: use devm_regulator_register()
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/tps6105x-regulator.c
b/drivers/regulator/tps6105x-regulator.c
index ec9453f..e0e818d 100644
--- a/drivers/regulator/tps6105x-regulator.c
+++ b/drivers/regulator/tps6105x-regulator.c
@@ -146,8 +146,9 @@ static int tps6105x_regulator_probe(struct platform_device
*pdev)
config.driver_data = tps6105x;
/* Register regulator with framework */
- tps6105x->regulator = regulator_register(_regulator_desc,
-);
+ tps6105x->regulator = devm_regulator_register(>dev,
+ _regulator_desc,
+ );
if (IS_ERR(tps6105x->regulator)) {
ret = PTR_ERR(tps6105x->regulator);
dev_err(>client->dev,
@@ -159,20 +160,12 @@ static int tps6105x_regulator_probe(struct
platform_device *pdev)
return 0;
}
-static int tps6105x_regulator_remove(struct platform_device *pdev)
-{
- struct tps6105x *tps6105x = dev_get_platdata(>dev);
- regulator_unregister(tps6105x->regulator);
- return 0;
-}
-
static struct platform_driver tps6105x_regulator_driver = {
.driver = {
.name = "tps6105x-regulator",
.owner = THIS_MODULE,
},
.probe = tps6105x_regulator_probe,
- .remove = tps6105x_regulator_remove,
};
static __init int tps6105x_regulator_init(void)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 09/14] regulator: pcap: use devm_regulator_register()
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/regulator/pcap-regulator.c
index b49eaee..3727b7d 100644
--- a/drivers/regulator/pcap-regulator.c
+++ b/drivers/regulator/pcap-regulator.c
@@ -246,7 +246,8 @@ static int pcap_regulator_probe(struct platform_device
*pdev)
config.init_data = dev_get_platdata(>dev);
config.driver_data = pcap;
- rdev = regulator_register(_regulators[pdev->id], );
+ rdev = devm_regulator_register(>dev, _regulators[pdev->id],
+ );
if (IS_ERR(rdev))
return PTR_ERR(rdev);
@@ -255,22 +256,12 @@ static int pcap_regulator_probe(struct platform_device
*pdev)
return 0;
}
-static int pcap_regulator_remove(struct platform_device *pdev)
-{
- struct regulator_dev *rdev = platform_get_drvdata(pdev);
-
- regulator_unregister(rdev);
-
- return 0;
-}
-
static struct platform_driver pcap_regulator_driver = {
.driver = {
.name = "pcap-regulator",
.owner = THIS_MODULE,
},
.probe = pcap_regulator_probe,
- .remove = pcap_regulator_remove,
};
static int __init pcap_regulator_init(void)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 10/14] regulator: pcf50633: use devm_regulator_register()
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/drivers/regulator/pcf50633-regulator.c
index 0f3576d..d7da1c1 100644
--- a/drivers/regulator/pcf50633-regulator.c
+++ b/drivers/regulator/pcf50633-regulator.c
@@ -90,7 +90,8 @@ static int pcf50633_regulator_probe(struct platform_device
*pdev)
config.driver_data = pcf;
config.regmap = pcf->regmap;
- rdev = regulator_register([pdev->id], );
+ rdev = devm_regulator_register(>dev, [pdev->id],
+ );
if (IS_ERR(rdev))
return PTR_ERR(rdev);
@@ -102,21 +103,11 @@ static int pcf50633_regulator_probe(struct
platform_device *pdev)
return 0;
}
-static int pcf50633_regulator_remove(struct platform_device *pdev)
-{
- struct regulator_dev *rdev = platform_get_drvdata(pdev);
-
- regulator_unregister(rdev);
-
- return 0;
-}
-
static struct platform_driver pcf50633_regulator_driver = {
.driver = {
.name = "pcf50633-regltr",
},
.probe = pcf50633_regulator_probe,
- .remove = pcf50633_regulator_remove,
};
static int __init pcf50633_regulator_init(void)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 08/14] regulator: max8925: use devm_regulator_register()
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/regulator/max8925-regulator.c
index d80b5fa..7595107 100644
--- a/drivers/regulator/max8925-regulator.c
+++ b/drivers/regulator/max8925-regulator.c
@@ -312,7 +312,7 @@ static int max8925_regulator_probe(struct platform_device
*pdev)
if (pdata)
config.init_data = pdata;
- rdev = regulator_register(>desc, );
+ rdev = devm_regulator_register(>dev, >desc, );
if (IS_ERR(rdev)) {
dev_err(>dev, "failed to register regulator %s\n",
ri->desc.name);
@@ -323,22 +323,12 @@ static int max8925_regulator_probe(struct platform_device
*pdev)
return 0;
}
-static int max8925_regulator_remove(struct platform_device *pdev)
-{
- struct regulator_dev *rdev = platform_get_drvdata(pdev);
-
- regulator_unregister(rdev);
-
- return 0;
-}
-
static struct platform_driver max8925_regulator_driver = {
.driver = {
.name = "max8925-regulator",
.owner = THIS_MODULE,
},
.probe = max8925_regulator_probe,
- .remove = max8925_regulator_remove,
};
static int __init max8925_regulator_init(void)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: Check real user/group id for %pK
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 all >> kptr_restrict is optional precisely because the benefit is marginal. >> >> The interesting question is what credentials make sense for %pK outside >> of a seq_printf(). Does it even make sense in a generic printk? In that >> case, it's the permission of the syslogd that matters rather than the >> process generating the message. >> >>> Will wait and see what others have to say. >> Me, too. Dan in particular. > > Firstly, I wouldn't recommend applying %pK's to printk usage. Sorry, the patch description should say 'vsprintf: ' not 'printk: '. Posting too early in the morning :-). > Removing > all addresses from the kernel syslog compromises its usefulness in > debugging basically anything at all. Additionally, many printk calls are > performed from a context where a capability check would yield > unpredictable (or at least meaningless) results. If you want to restrict > access to the kernel syslog by unprivileged users, that should be done > by enabling CONFIG_DMESG_RESTRICT, which was written for this purpose. Agreed. > With that out of the way, I don't have a strong opinion on how to handle > this case. The proposed patch solves the problem but may break setuid > applications that expect to be able to read /proc/kallsyms contents > based on euid (and implicitly, capabilities) alone. But then again, > these mythical setuid applications are probably broken in some > situations anyway, because what happens if /proc/kallsyms is set to "2" > (unconditionally replace addresses with 0's)? I also can't think of a > better solution. 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 -- 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 V4 06/14] regulator: lp8788-buck: use devm_regulator_register()
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/lp8788-buck.c
index 0b015f2..948afc2 100644
--- a/drivers/regulator/lp8788-buck.c
+++ b/drivers/regulator/lp8788-buck.c
@@ -515,7 +515,7 @@ static int lp8788_buck_probe(struct platform_device *pdev)
cfg.driver_data = buck;
cfg.regmap = lp->regmap;
- rdev = regulator_register(_buck_desc[id], );
+ rdev = devm_regulator_register(>dev, _buck_desc[id], );
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
dev_err(>dev, "BUCK%d regulator register err = %d\n",
@@ -529,18 +529,8 @@ static int lp8788_buck_probe(struct platform_device *pdev)
return 0;
}
-static int lp8788_buck_remove(struct platform_device *pdev)
-{
- struct lp8788_buck *buck = platform_get_drvdata(pdev);
-
- regulator_unregister(buck->regulator);
-
- return 0;
-}
-
static struct platform_driver lp8788_buck_driver = {
.probe = lp8788_buck_probe,
- .remove = lp8788_buck_remove,
.driver = {
.name = LP8788_DEV_BUCK,
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 07/14] regulator: lp8788-ldo: use devm_regulator_register()
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/regulator/lp8788-ldo.c
index 0527d87..b9a29a2 100644
--- a/drivers/regulator/lp8788-ldo.c
+++ b/drivers/regulator/lp8788-ldo.c
@@ -543,7 +543,7 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
cfg.driver_data = ldo;
cfg.regmap = lp->regmap;
- rdev = regulator_register(_dldo_desc[id], );
+ rdev = devm_regulator_register(>dev, _dldo_desc[id], );
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
dev_err(>dev, "DLDO%d regulator register err = %d\n",
@@ -557,18 +557,8 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
return 0;
}
-static int lp8788_dldo_remove(struct platform_device *pdev)
-{
- struct lp8788_ldo *ldo = platform_get_drvdata(pdev);
-
- regulator_unregister(ldo->regulator);
-
- return 0;
-}
-
static struct platform_driver lp8788_dldo_driver = {
.probe = lp8788_dldo_probe,
- .remove = lp8788_dldo_remove,
.driver = {
.name = LP8788_DEV_DLDO,
.owner = THIS_MODULE,
@@ -603,7 +593,7 @@ static int lp8788_aldo_probe(struct platform_device *pdev)
cfg.driver_data = ldo;
cfg.regmap = lp->regmap;
- rdev = regulator_register(_aldo_desc[id], );
+ rdev = devm_regulator_register(>dev, _aldo_desc[id], );
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
dev_err(>dev, "ALDO%d regulator register err = %d\n",
@@ -617,18 +607,8 @@ static int lp8788_aldo_probe(struct platform_device *pdev)
return 0;
}
-static int lp8788_aldo_remove(struct platform_device *pdev)
-{
- struct lp8788_ldo *ldo = platform_get_drvdata(pdev);
-
- regulator_unregister(ldo->regulator);
-
- return 0;
-}
-
static struct platform_driver lp8788_aldo_driver = {
.probe = lp8788_aldo_probe,
- .remove = lp8788_aldo_remove,
.driver = {
.name = LP8788_DEV_ALDO,
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 05/14] regulator: lp872x: use devm_regulator_register()
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/regulator/lp872x.c
index 2b84b72..2e4734f 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -785,7 +785,7 @@ static int lp872x_regulator_register(struct lp872x *lp)
struct regulator_desc *desc;
struct regulator_config cfg = { };
struct regulator_dev *rdev;
- int i, ret;
+ int i;
for (i = 0; i < lp->num_regulators; i++) {
desc = (lp->chipid == LP8720) ? _regulator_desc[i] :
@@ -796,34 +796,16 @@ static int lp872x_regulator_register(struct lp872x *lp)
cfg.driver_data = lp;
cfg.regmap = lp->regmap;
- rdev = regulator_register(desc, );
+ rdev = devm_regulator_register(lp->dev, desc, );
if (IS_ERR(rdev)) {
dev_err(lp->dev, "regulator register err");
- ret = PTR_ERR(rdev);
- goto err;
+ return PTR_ERR(rdev);
}
*(lp->regulators + i) = rdev;
}
return 0;
-err:
- while (--i >= 0) {
- rdev = *(lp->regulators + i);
- regulator_unregister(rdev);
- }
- return ret;
-}
-
-static void lp872x_regulator_unregister(struct lp872x *lp)
-{
- struct regulator_dev *rdev;
- int i;
-
- for (i = 0; i < lp->num_regulators; i++) {
- rdev = *(lp->regulators + i);
- regulator_unregister(rdev);
- }
}
static const struct regmap_config lp872x_regmap_config = {
@@ -979,14 +961,6 @@ err_dev:
return ret;
}
-static int lp872x_remove(struct i2c_client *cl)
-{
- struct lp872x *lp = i2c_get_clientdata(cl);
-
- lp872x_regulator_unregister(lp);
- return 0;
-}
-
static const struct of_device_id lp872x_dt_ids[] = {
{ .compatible = "ti,lp8720", },
{ .compatible = "ti,lp8725", },
@@ -1008,7 +982,6 @@ static struct i2c_driver lp872x_driver = {
.of_match_table = of_match_ptr(lp872x_dt_ids),
},
.probe = lp872x_probe,
- .remove = lp872x_remove,
.id_table = lp872x_ids,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 04/14] regulator: da9210: use devm_regulator_register()
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/regulator/da9210-regulator.c
index f7ccff1..6f5ecbe 100644
--- a/drivers/regulator/da9210-regulator.c
+++ b/drivers/regulator/da9210-regulator.c
@@ -155,7 +155,7 @@ static int da9210_i2c_probe(struct i2c_client *i2c,
config.regmap = chip->regmap;
config.of_node = dev->of_node;
- rdev = regulator_register(_reg, );
+ rdev = devm_regulator_register(>dev, _reg, );
if (IS_ERR(rdev)) {
dev_err(>dev, "Failed to register DA9210 regulator\n");
return PTR_ERR(rdev);
@@ -168,13 +168,6 @@ static int da9210_i2c_probe(struct i2c_client *i2c,
return 0;
}
-static int da9210_i2c_remove(struct i2c_client *i2c)
-{
- struct da9210 *chip = i2c_get_clientdata(i2c);
- regulator_unregister(chip->rdev);
- return 0;
-}
-
static const struct i2c_device_id da9210_i2c_id[] = {
{"da9210", 0},
{},
@@ -188,7 +181,6 @@ static struct i2c_driver da9210_regulator_driver = {
.owner = THIS_MODULE,
},
.probe = da9210_i2c_probe,
- .remove = da9210_i2c_remove,
.id_table = da9210_i2c_id,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 03/14] regulator: da9063: use devm_regulator_register()
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.c
index 3d910f4..56727eb 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -847,13 +847,13 @@ static int da9063_regulator_probe(struct platform_device
*pdev)
if (da9063_reg_matches)
config.of_node = da9063_reg_matches[id].of_node;
config.regmap = da9063->regmap;
- regl->rdev = regulator_register(>desc, );
+ regl->rdev = devm_regulator_register(>dev, >desc,
+);
if (IS_ERR(regl->rdev)) {
dev_err(>dev,
"Failed to register %s regulator\n",
regl->desc.name);
- ret = PTR_ERR(regl->rdev);
- goto err;
+ return PTR_ERR(regl->rdev);
}
id++;
n++;
@@ -862,9 +862,8 @@ static int da9063_regulator_probe(struct platform_device
*pdev)
/* LDOs overcurrent event support */
irq = platform_get_irq_byname(pdev, "LDO_LIM");
if (irq < 0) {
- ret = irq;
dev_err(>dev, "Failed to get IRQ.\n");
- goto err;
+ return irq;
}
regulators->irq_ldo_lim = regmap_irq_get_virq(da9063->regmap_irq, irq);
@@ -881,27 +880,15 @@ static int da9063_regulator_probe(struct platform_device
*pdev)
}
return 0;
-
-err:
- /* Wind back regulators registeration */
- while (--n >= 0)
- regulator_unregister(regulators->regulator[n].rdev);
-
- return ret;
}
static int da9063_regulator_remove(struct platform_device *pdev)
{
struct da9063_regulators *regulators = platform_get_drvdata(pdev);
- struct da9063_regulator *regl;
free_irq(regulators->irq_ldo_lim, regulators);
free_irq(regulators->irq_uvov, regulators);
- for (regl = >regulator[regulators->n_regulators - 1];
-regl >= >regulator[0]; regl--)
- regulator_unregister(regl->rdev);
-
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 02/14] regulator: ab8500-ext: use devm_regulator_register()
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/regulator/ab8500-ext.c
index 02ff691..29c0faa 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -413,16 +413,12 @@ static int ab8500_ext_regulator_probe(struct
platform_device *pdev)
>ext_regulator[i];
/* register regulator with framework */
- info->rdev = regulator_register(>desc, );
+ info->rdev = devm_regulator_register(>dev, >desc,
+);
if (IS_ERR(info->rdev)) {
err = PTR_ERR(info->rdev);
dev_err(>dev, "failed to register regulator %s\n",
info->desc.name);
- /* when we fail, un-register all earlier regulators */
- while (--i >= 0) {
- info = _ext_regulator_info[i];
- regulator_unregister(info->rdev);
- }
return err;
}
@@ -433,26 +429,8 @@ static int ab8500_ext_regulator_probe(struct
platform_device *pdev)
return 0;
}
-static int ab8500_ext_regulator_remove(struct platform_device *pdev)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(ab8500_ext_regulator_info); i++) {
- struct ab8500_ext_regulator_info *info = NULL;
- info = _ext_regulator_info[i];
-
- dev_vdbg(rdev_get_dev(info->rdev),
- "%s-remove\n", info->desc.name);
-
- regulator_unregister(info->rdev);
- }
-
- return 0;
-}
-
static struct platform_driver ab8500_ext_regulator_driver = {
.probe = ab8500_ext_regulator_probe,
- .remove = ab8500_ext_regulator_remove,
.driver = {
.name = "ab8500-ext-regulator",
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rwsem: reduce spinlock contention in wakeup code path
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 forget the details, but it was something people worried about. That mm_take_all_locks() thing is really special, and I suspect that if we go down this way we should just do a single preempt-disable and then use the arch_write_lock() to avoid both the lockdep splat _and_ the preemption counter overflow. 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/
[PATCH V4 01/14] regulator: ab3100: use devm_regulator_register()
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 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -535,7 +535,7 @@ static int ab3100_regulator_register(struct platform_device
*pdev,
config.dev = >dev;
config.driver_data = reg;
- rdev = regulator_register(desc, );
+ rdev = devm_regulator_register(>dev, desc, );
if (IS_ERR(rdev)) {
err = PTR_ERR(rdev);
dev_err(>dev,
@@ -616,7 +616,6 @@ static int ab3100_regulators_remove(struct platform_device
*pdev)
for (i = 0; i < AB3100_NUM_REGULATORS; i++) {
struct ab3100_regulator *reg = _regulators[i];
- regulator_unregister(reg->rdev);
reg->rdev = NULL;
}
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 12/14] regulator: tps6524x: use devm_regulator_register()
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, you can add Reviewed-by: Axel Lin > OK, I will fix it as you guided. I will send V4 patch series soon. Thank you for your kind and detailed guidance. :-) Best regards, Jingoo Han -- 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] printk: Check real user/group id for %pK
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 because the benefit is marginal. > > The interesting question is what credentials make sense for %pK outside > of a seq_printf(). Does it even make sense in a generic printk? In that > case, it's the permission of the syslogd that matters rather than the > process generating the message. > >> Will wait and see what others have to say. > Me, too. Dan in particular. Firstly, I wouldn't recommend applying %pK's to printk usage. Removing all addresses from the kernel syslog compromises its usefulness in debugging basically anything at all. Additionally, many printk calls are performed from a context where a capability check would yield unpredictable (or at least meaningless) results. If you want to restrict access to the kernel syslog by unprivileged users, that should be done by enabling CONFIG_DMESG_RESTRICT, which was written for this purpose. With that out of the way, I don't have a strong opinion on how to handle this case. The proposed patch solves the problem but may break setuid applications that expect to be able to read /proc/kallsyms contents based on euid (and implicitly, capabilities) alone. But then again, these mythical setuid applications are probably broken in some situations anyway, because what happens if /proc/kallsyms is set to "2" (unconditionally replace addresses with 0's)? I also can't think of a better solution. -Dan -- 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] rwsem: reduce spinlock contention in wakeup code path
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_mmap_mutex, having a similar responsibility
> > to the anon-vma lock with file backed pages. A few months ago I had
> > suggested changing that lock to rwsem, giving some pretty reasonable
> > performance improvement numbers.
> >
> > http://lwn.net/Articles/556342/
>
> Ok, that's pretty convincing too.
>
> Side note: are you sure that the i_mmap_mutex needs to be a sleeping
> lock at all? It's documented to nest outside the anon_vma->rwsem, so
> as long as that is a sleeping lock, the i_mmap_mutex needs to be one
> too, but looking at the actual users, most of them seem to be *very*
> similar to the anon_vma->rwsem users. It is a very close cousin to the
> anon_vma->rwsem, after all (just for file-backed pages rather than
> anonymous ones). No?
Right, I brought that up exactly because it is so similar to the
anon-vma lock. Both should really be the same type, whether it be rwsem
or rwlock. Hopefully the rwlock conversion tests will also benefit just
like Ingo's patch did, I should have numbers early next week.
>
> I dunno. Maybe the ranges are too big and it really has latency
> issues, the few I looked at looked like fairly trivial interval-tree
> operations, though.
>
> 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
> > show hardly any difference, but those that really contend this lock
> > (with high amounts of users) benefited quite nicely:
> >
> > Alltests: +28% throughput after 1000 users and runtime was reduced from
> > 7.2 to 6.6 secs.
> >
> > Custom: +61% throughput after 100 users and runtime was reduced from 7
> > to 4.9 secs.
> >
> > High_systime: +40% throughput after 1000 users and runtime was reduced
> > from 19 to 15.5 secs.
> >
> > Shared: +30.5% throughput after 100 users and runtime was reduced from
> > 6.5 to 5.1 secs.
> >
> > Short: Lots of variance in the numbers, but avg of +29% throughput - no
> > particular performance degradation either.
>
> Are just overwhelming, in my opinion. The conversion *from* a spinlock
> never had this kind of support behind it.
>
> Btw, did anybody run Ingo's patch with lockdep and the spinlock sleep
> debugging code to verify that we haven't introduced any problems wrt
> sleeping since the lock was converted into a rw-semaphore?
Hmm, I'm getting the following at bootup:
=
[ INFO: possible recursive locking detected ]
3.12.0-rc2+ #7 Not tainted
-
qemu-kvm/64239 is trying to acquire lock:
(_vma->rwlock){+.+...}, at: []
mm_take_all_locks+0x146/0x190
but task is already holding lock:
(_vma->rwlock){+.+...}, at: []
mm_take_all_locks+0x146/0x190
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_vma->rwlock);
lock(_vma->rwlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by qemu-kvm/64239:
#0: (>mmap_sem){++}, at: []
do_mmu_notifier_register+0x13c/0x180
#1: (mm_all_locks_mutex){+.+...}, at: []
mm_take_all_locks+0x3b/0x190
#2: (>i_mmap_mutex){+.+...}, at: []
mm_take_all_locks+0xc6/0x190
#3: (_vma->rwlock){+.+...}, at: []
mm_take_all_locks+0x146/0x190
stack backtrace:
CPU: 51 PID: 64239 Comm: qemu-kvm Not tainted 3.12.0-rc2+ #7
Hardware name: HP ProLiant DL980 G7, BIOS P66 06/24/2011
8b9f79294a80 8a9f7c375c08 815802dc 0003
8b9f79294100 8a9f7c375c38 810bda34 8b9f79294100
8b9f79294a80 8b9f79294100 8a9f7c375c98
Call Trace:
[] dump_stack+0x49/0x5d
[] print_deadlock_bug+0xf4/0x100
[] validate_chain+0x504/0x7a0
[] __lock_acquire+0x30d/0x590
[] ? mm_take_all_locks+0x146/0x190
[] lock_acquire+0xa0/0x110
[] ? mm_take_all_locks+0x146/0x190
[] ? trace_hardirqs_on+0xd/0x10
[] _raw_write_lock+0x31/0x40
[] ? mm_take_all_locks+0x146/0x190
[] mm_take_all_locks+0x146/0x190
[] do_mmu_notifier_register+0x76/0x180
[] mmu_notifier_register+0x13/0x20
[] kvm_create_vm+0x22c/0x300 [kvm]
[] kvm_dev_ioctl+0xb8/0x140 [kvm]
[] do_vfs_ioctl+0x89/0x350
[] ? sysret_check+0x1b/0x56
[] SyS_ioctl+0xa1/0xb0
This is probably due to the change in vm_lock_anon_vma():
- down_write_nest_lock(_vma->root->rwsem, >mmap_sem);
+ write_lock(_vma->root->rwlock);
--
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
Re: [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
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 support no longer compiles with this patch:
>
> CC drivers/iommu/exynos-iommu.o
> /mnt/host/source/src/third_party/kernel-next/drivers/iommu/exynos-iommu.c:32:25:
> fatal error: mach/sysmmu.h: No such file or directory
> compilation terminated.
> make[3]: *** [drivers/iommu/exynos-iommu.o] Error 1
>
It is my fault.
I think you need to apply all v6 patches to compile correctly.
Since v8 patches, I checked that every patch is compiled successfully.
iommu/exynos: do not include removed header
patch from v7 patch removes including 'mach/sysmmu.h'.
Thank you.
> Sean
>
>
> > Signed-off-by: KyongHo Cho
> > ---
> > arch/arm/mach-exynos/Kconfig | 5 -
> > arch/arm/mach-exynos/Makefile | 1 -
> > arch/arm/mach-exynos/clock-exynos4.c | 41 +++--
> > arch/arm/mach-exynos/clock-exynos4210.c| 9 +-
> > arch/arm/mach-exynos/clock-exynos4212.c| 23 ++-
> > arch/arm/mach-exynos/clock-exynos5.c | 62 ---
> > arch/arm/mach-exynos/dev-sysmmu.c | 274
> > -
> > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 ---
> > arch/arm/mach-exynos/mach-exynos4-dt.c | 34
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 30
> > 10 files changed, 137 insertions(+), 408 deletions(-)
> > delete mode 100644 arch/arm/mach-exynos/dev-sysmmu.c
> > delete mode 100644 arch/arm/mach-exynos/include/mach/sysmmu.h
> >
> > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> > index 91d5b6f..eba6eb5 100644
> > --- a/arch/arm/mach-exynos/Kconfig
> > +++ b/arch/arm/mach-exynos/Kconfig
> > @@ -103,11 +103,6 @@ config EXYNOS4_SETUP_FIMD0
> > help
> > Common setup code for FIMD0.
> >
> > -config EXYNOS_DEV_SYSMMU
> > - bool
> > - help
> > - Common setup code for SYSTEM MMU in EXYNOS platforms
> > -
> > config EXYNOS4_DEV_USB_OHCI
> > bool
> > help
> > diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> > index b189881..435757e 100644
> > --- a/arch/arm/mach-exynos/Makefile
> > +++ b/arch/arm/mach-exynos/Makefile
> > @@ -52,7 +52,6 @@ obj-$(CONFIG_ARCH_EXYNOS4)+= dev-audio.o
> > obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
> > obj-$(CONFIG_EXYNOS_DEV_DMA) += dma.o
> > obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o
> > -obj-$(CONFIG_EXYNOS_DEV_SYSMMU)+= dev-sysmmu.o
> >
> > obj-$(CONFIG_ARCH_EXYNOS) += setup-i2c0.o
> > obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
> > diff --git a/arch/arm/mach-exynos/clock-exynos4.c
> > b/arch/arm/mach-exynos/clock-exynos4.c
> > index bbcb3de..8a8468d 100644
> > --- a/arch/arm/mach-exynos/clock-exynos4.c
> > +++ b/arch/arm/mach-exynos/clock-exynos4.c
> > @@ -24,7 +24,6 @@
> >
> > #include
> > #include
> > -#include
> >
> > #include "common.h"
> > #include "clock-exynos4.h"
> > @@ -709,53 +708,53 @@ static struct clk exynos4_init_clocks_off[] = {
> > .enable = exynos4_clk_ip_peril_ctrl,
> > .ctrlbit= (1 << 14),
> > }, {
> > - .name = SYSMMU_CLOCK_NAME,
> > - .devname= SYSMMU_CLOCK_DEVNAME(mfc_l, 0),
> > + .name = "sysmmu",
> > + .devname= "exynos-sysmmu.0",
> > .enable = exynos4_clk_ip_mfc_ctrl,
> > .ctrlbit= (1 << 1),
> > }, {
> > - .name = SYSMMU_CLOCK_NAME,
> > - .devname= SYSMMU_CLOCK_DEVNAME(mfc_r, 1),
> > + .name = "sysmmu",
> > + .devname= "exynos-sysmmu.1",
> > .enable = exynos4_clk_ip_mfc_ctrl,
> > .ctrlbit= (1 << 2),
> > }, {
> > - .name = SYSMMU_CLOCK_NAME,
> > - .devname= SYSMMU_CLOCK_DEVNAME(tv, 2),
> > + .name = "sysmmu",
> > + .devname= "exynos-sysmmu.2",
> > .enable = exynos4_clk_ip_tv_ctrl,
> > .ctrlbit= (1 << 4),
> > }, {
> > - .name = SYSMMU_CLOCK_NAME,
> > - .devname= SYSMMU_CLOCK_DEVNAME(jpeg, 3),
> > + .name = "sysmmu",
> > + .devname= "exynos-sysmmu.3",
> > .enable = exynos4_clk_ip_cam_ctrl,
> > .ctrlbit= (1 << 11),
> > }, {
> > - .name = SYSMMU_CLOCK_NAME,
> > - .devname= SYSMMU_CLOCK_DEVNAME(rot, 4),
> >
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
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/snapshot.c |5 -
kernel/power/user.c |8
2 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-pm/kernel/power/snapshot.c
===
--- linux-pm.orig/kernel/power/snapshot.c
+++ linux-pm/kernel/power/snapshot.c
@@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void)
struct memory_bitmap *bm1, *bm2;
int error = 0;
- BUG_ON(forbidden_pages_map || free_pages_map);
+ if (forbidden_pages_map && free_pages_map)
+ return 0;
+ else
+ BUG_ON(forbidden_pages_map || free_pages_map);
bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
if (!bm1)
Index: linux-pm/kernel/power/user.c
===
--- linux-pm.orig/kernel/power/user.c
+++ linux-pm/kernel/power/user.c
@@ -39,6 +39,7 @@ static struct snapshot_data {
char frozen;
char ready;
char platform_support;
+ bool free_bitmaps;
} snapshot_state;
atomic_t snapshot_device_available = ATOMIC_INIT(1);
@@ -82,6 +83,10 @@ static int snapshot_open(struct inode *i
data->swap = -1;
data->mode = O_WRONLY;
error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
+ if (!error) {
+ error = create_basic_memory_bitmaps();
+ data->free_bitmaps = !error;
+ }
if (error)
pm_notifier_call_chain(PM_POST_RESTORE);
}
@@ -111,6 +116,8 @@ static int snapshot_release(struct inode
pm_restore_gfp_mask();
free_basic_memory_bitmaps();
thaw_processes();
+ } else if (data->free_bitmaps) {
+ free_basic_memory_bitmaps();
}
pm_notifier_call_chain(data->mode == O_RDONLY ?
PM_POST_HIBERNATION : PM_POST_RESTORE);
@@ -231,6 +238,7 @@ static long snapshot_ioctl(struct file *
break;
pm_restore_gfp_mask();
free_basic_memory_bitmaps();
+ data->free_bitmaps = false;
thaw_processes();
data->frozen = 0;
break;
--
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/
[stable 3.11] [PATCH] irq: Always define devm_{request_threaded,free}_irq()
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/fetch.php?pkg=linux=s390=3.11%7Erc4-1%7Eexp1=1376009959 Signed-off-by: Ben Hutchings --- kernel/Makefile | 2 +- kernel/irq/Makefile | 6 -- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index 35ef118..ed2c9a9 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -79,7 +79,7 @@ obj-$(CONFIG_KPROBES) += kprobes.o obj-$(CONFIG_KGDB) += debug/ obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o -obj-$(CONFIG_GENERIC_HARDIRQS) += irq/ +obj-y += irq/ obj-$(CONFIG_SECCOMP) += seccomp.o obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o obj-$(CONFIG_TREE_RCU) += rcutree.o diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile index fff1738..639b2e1 100644 --- a/kernel/irq/Makefile +++ b/kernel/irq/Makefile @@ -1,8 +1,10 @@ - -obj-y := irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o devres.o +obj-y += devres.o +ifdef CONFIG_GENERIC_HARDIRQS +obj-y += irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o obj-$(CONFIG_GENERIC_IRQ_CHIP) += generic-chip.o obj-$(CONFIG_GENERIC_IRQ_PROBE) += autoprobe.o obj-$(CONFIG_IRQ_DOMAIN) += irqdomain.o obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o obj-$(CONFIG_PM_SLEEP) += pm.o +endif -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
[GIT] Apparmor fixes for 3.12
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.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
for-linus
John Johansen (1):
apparmor: fix suspicious RCU usage warning in policy.c/policy.h
Tyler Hicks (1):
apparmor: Use shash crypto API interface for profile hashes
security/apparmor/crypto.c | 34 --
security/apparmor/include/policy.h |4 +++-
security/apparmor/policy.c |3 ++-
3 files changed, 21 insertions(+), 20 deletions(-)
commit 4cd4fc77032dca46fe7475d81461e29145db247a
Author: John Johansen
Date: Sun Sep 29 08:39:22 2013 -0700
apparmor: fix suspicious RCU usage warning in policy.c/policy.h
The recent 3.12 pull request for apparmor was missing a couple rcu
_protected
access modifiers. Resulting in the follow suspicious RCU usage
[ 29.804534] [ INFO: suspicious RCU usage. ]
[ 29.804539] 3.11.0+ #5 Not tainted
[ 29.804541] ---
[ 29.804545] security/apparmor/include/policy.h:363 suspicious
rcu_dereference_check() usage!
[ 29.804548]
[ 29.804548] other info that might help us debug this:
[ 29.804548]
[ 29.804553]
[ 29.804553] rcu_scheduler_active = 1, debug_locks = 1
[ 29.804558] 2 locks held by apparmor_parser/1268:
[ 29.804560] #0: (sb_writers#9){.+.+.+}, at: []
file_start_write+0x27/0x29
[ 29.804576] #1: (>lock){+.+.+.}, at: []
aa_replace_profiles+0x166/0x57c
[ 29.804589]
[ 29.804589] stack backtrace:
[ 29.804595] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+
#5
[ 29.804599] Hardware name: ASUSTeK Computer Inc. UL50VT
/UL50VT, BIOS 217 03/01/2010
[ 29.804602] 8800b95a1d90 8144eb9b
8800b94db540
[ 29.804611] 8800b95a1dc0 81087439 880138cc3a18
880138cc3a18
[ 29.804619] 8800b9464a90 880138cc3a38 8800b95a1df0
811f5084
[ 29.804628] Call Trace:
[ 29.804636] [] dump_stack+0x4e/0x82
[ 29.804642] [] lockdep_rcu_suspicious+0xfc/0x105
[ 29.804649] [] __aa_update_replacedby+0x53/0x7f
[ 29.804655] [] __replace_profile+0x11f/0x1ed
[ 29.804661] [] aa_replace_profiles+0x410/0x57c
[ 29.804668] [] profile_replace+0x35/0x4c
[ 29.804674] [] vfs_write+0xad/0x113
[ 29.804680] [] SyS_write+0x44/0x7a
[ 29.804687] [] system_call_fastpath+0x16/0x1b
[ 29.804691]
[ 29.804694] ===
[ 29.804697] [ INFO: suspicious RCU usage. ]
[ 29.804700] 3.11.0+ #5 Not tainted
[ 29.804703] ---
[ 29.804706] security/apparmor/policy.c:566 suspicious
rcu_dereference_check() usage!
[ 29.804709]
[ 29.804709] other info that might help us debug this:
[ 29.804709]
[ 29.804714]
[ 29.804714] rcu_scheduler_active = 1, debug_locks = 1
[ 29.804718] 2 locks held by apparmor_parser/1268:
[ 29.804721] #0: (sb_writers#9){.+.+.+}, at: []
file_start_write+0x27/0x29
[ 29.804733] #1: (>lock){+.+.+.}, at: []
aa_replace_profiles+0x166/0x57c
[ 29.804744]
[ 29.804744] stack backtrace:
[ 29.804750] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+
#5
[ 29.804753] Hardware name: ASUSTeK Computer Inc. UL50VT
/UL50VT, BIOS 217 03/01/2010
[ 29.804756] 8800b95a1d80 8144eb9b
8800b94db540
[ 29.804764] 8800b95a1db0 81087439 8800b95b02b0
[ 29.804772] 8800b9efba08 880138cc3a38 8800b95a1dd0
811f4f94
[ 29.804779] Call Trace:
[ 29.804786] [] dump_stack+0x4e/0x82
[ 29.804791] [] lockdep_rcu_suspicious+0xfc/0x105
[ 29.804798] [] aa_free_replacedby_kref+0x4d/0x62
[ 29.804804] [] ? aa_put_namespace+0x17/0x17
[ 29.804810] [] kref_put+0x36/0x40
[ 29.804816] [] __replace_profile+0x13a/0x1ed
[ 29.804822] [] aa_replace_profiles+0x410/0x57c
[ 29.804829] [] profile_replace+0x35/0x4c
[ 29.804835] [] vfs_write+0xad/0x113
[ 29.804840] [] SyS_write+0x44/0x7a
[ 29.804847] [] system_call_fastpath+0x16/0x1b
Reported-by: miles.l...@gmail.com
CC: paul...@linux.vnet.ibm.com
Signed-off-by: John Johansen
Signed-off-by: James Morris
diff --git a/security/apparmor/include/policy.h
b/security/apparmor/include/policy.h
index f2d4b63..c28b0f2 100644
--- a/security/apparmor/include/policy.h
+++ b/security/apparmor/include/policy.h
@@ -360,7 +360,9
Re: [ 062/117] ext4: fix ext4_writepages() in presence of truncate
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 5f1132b2ba8c873f25982cf45917e8455fb6c962 upstream. > [...] > > Is this needed for any older kernel versions? I can't speak authoriatively, but I only started triggering it with 3.11-rc. Dave -- 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] printk: Check real user/group id for %pK
> 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 question is what credentials make sense for %pK outside of a seq_printf(). Does it even make sense in a generic printk? In that case, it's the permission of the syslogd that matters rather than the process generating the message. > Will wait and see what others have to say. Me, too. Dan in particular. -- 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] extcon: arizona: Get pdata from arizona structure not device
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 it is populated by the MFD device which
> binds in the extcon driver.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index ec9a14e..178454d 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1079,7 +1079,7 @@ static void arizona_micd_set_level(struct arizona
> *arizona, int index,
> static int arizona_extcon_probe(struct platform_device *pdev)
> {
> struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
> - struct arizona_pdata *pdata;
> + struct arizona_pdata *pdata = >pdata;
> struct arizona_extcon_info *info;
> unsigned int val;
> int jack_irq_fall, jack_irq_rise;
> @@ -1088,8 +1088,6 @@ static int arizona_extcon_probe(struct platform_device
> *pdev)
> if (!arizona->dapm || !arizona->dapm->card)
> return -EPROBE_DEFER;
>
> - pdata = dev_get_platdata(arizona->dev);
> -
> info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
> if (!info) {
> dev_err(>dev, "Failed to allocate memory\n");
>
No, extcon-arizona driver don't currently support DT to get platform data.
I cannot find some dt function to parse data from dts file.
You have to implement extcon-arizona driver by using DT binding style
to get platform data. I think this patch is not necessary.
Thanks
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] printk: Check real user/group id for %pK
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 applications (e.g. perf?)
which are expecting to be able to read %pK values if invoked setuid. The
problem is that allowing that can potentially be used to leak
information too.
>
> The fundamental problem is that %pK is using permissions at the time
> of the read(), while the general Unix rule that setuid programs expect
> is that permission is checked at open() time. pppd is an example; its
> options_fom_file() function (pppd/options.c:391 in the 2.4.5 release)
> does:
>
> euid = geteuid();
> if (check_prot && seteuid(getuid()) == -1) {
> option_error("unable to drop privileges to open %s: %m", filename);
> return 0;
> }
> f = fopen(filename, "r");
> err = errno;
> if (check_prot && seteuid(euid) == -1)
> fatal("unable to regain privileges");
>
Right, so the pppd application is actually doing the correct thing.
>
> Now the whole struct cred and capability system is something I don't
> really understand, but it is clear from a brief look at the code
> that getting the appropriate credential through the seq_file to
> lib/vsprintf.c:pointer() would be tricky.
:-).
>
> But it also seems like the Right Thing to do; other fixes seem like
> ineffective kludges.
Will wait and see what others have to say.
(also apologies for the badly formatted initial post. The mail client on
my other machine is apparently not configured properly).
Thanks,
~Ryan
--
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] rwsem: reduce spinlock contention in wakeup code path
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 file backed pages. A few months ago I had > suggested changing that lock to rwsem, giving some pretty reasonable > performance improvement numbers. > > http://lwn.net/Articles/556342/ Ok, that's pretty convincing too. Side note: are you sure that the i_mmap_mutex needs to be a sleeping lock at all? It's documented to nest outside the anon_vma->rwsem, so as long as that is a sleeping lock, the i_mmap_mutex needs to be one too, but looking at the actual users, most of them seem to be *very* similar to the anon_vma->rwsem users. It is a very close cousin to the anon_vma->rwsem, after all (just for file-backed pages rather than anonymous ones). No? I dunno. Maybe the ranges are too big and it really has latency issues, the few I looked at looked like fairly trivial interval-tree operations, though. 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 > show hardly any difference, but those that really contend this lock > (with high amounts of users) benefited quite nicely: > > Alltests: +28% throughput after 1000 users and runtime was reduced from > 7.2 to 6.6 secs. > > Custom: +61% throughput after 100 users and runtime was reduced from 7 > to 4.9 secs. > > High_systime: +40% throughput after 1000 users and runtime was reduced > from 19 to 15.5 secs. > > Shared: +30.5% throughput after 100 users and runtime was reduced from > 6.5 to 5.1 secs. > > Short: Lots of variance in the numbers, but avg of +29% throughput - no > particular performance degradation either. Are just overwhelming, in my opinion. The conversion *from* a spinlock never had this kind of support behind it. Btw, did anybody run Ingo's patch with lockdep and the spinlock sleep debugging code to verify that we haven't introduced any problems wrt sleeping since the lock was converted into a rw-semaphore? Because quite frankly, considering these kinds of numbers, I really don't see how we could possibly make excuses for keeping that rw-semaphore unless there is some absolutely _horrible_ latency issue? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: Check real user/group id for %pK
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 Unix rule that setuid programs expect
is that permission is checked at open() time. pppd is an example; its
options_fom_file() function (pppd/options.c:391 in the 2.4.5 release)
does:
euid = geteuid();
if (check_prot && seteuid(getuid()) == -1) {
option_error("unable to drop privileges to open %s: %m", filename);
return 0;
}
f = fopen(filename, "r");
err = errno;
if (check_prot && seteuid(euid) == -1)
fatal("unable to regain privileges");
Now the whole struct cred and capability system is something I don't
really understand, but it is clear from a brief look at the code
that getting the appropriate credential through the seq_file to
lib/vsprintf.c:pointer() would be tricky.
But it also seems like the Right Thing to do; other fixes seem like
ineffective kludges.
--
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: [ 062/117] ext4: fix ext4_writepages() in presence of truncate
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? Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. -- 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] rwsem: reduce spinlock contention in wakeup code path
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: > > > > 5a505085f043 mm/rmap: Convert the struct anon_vma::mutex to an rwsem > > > > ... and Tim's patches turn that regression into an actual speedup. > > 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 file backed pages. A few months ago I had suggested changing that lock to rwsem, giving some pretty reasonable performance improvement numbers. http://lwn.net/Articles/556342/ > > Because you guys talk about the regression of turning it into a rwsem, > but nobody talks about the *original* regression. > > And it *used* to be a spinlock, and it was changed into a mutex back > in 2011 by commit 2b575eb64f7a. That commit doesn't even have a reason > listed for it, although my dim memory of it is that the reason was > preemption latency. > > And that caused big regressions too. 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 show hardly any difference, but those that really contend this lock (with high amounts of users) benefited quite nicely: Alltests: +28% throughput after 1000 users and runtime was reduced from 7.2 to 6.6 secs. Custom: +61% throughput after 100 users and runtime was reduced from 7 to 4.9 secs. High_systime: +40% throughput after 1000 users and runtime was reduced from 19 to 15.5 secs. Shared: +30.5% throughput after 100 users and runtime was reduced from 6.5 to 5.1 secs. Short: Lots of variance in the numbers, but avg of +29% throughput - no particular performance degradation either. The only workload that took a hit was fserver with a -6% throughput for small amounts of users (10-100). Theoretically at least, adding queuing to the rwlocks should only help the situation furthermore. I'll also run some test for a similar conversion for the i_mmap mutex next week. Going back to the rwsems, I believe adding optimistic spinning is still valid, independent of the anon-vma lock as it benefits all users. Thanks, Davidlohr -- 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/
Linux 3.12-rc3
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 now. If you ignore the mm changes, the rest looks very normal: the bulk is drivers (gpu, dm/bcache, usb, sound..), with the usual sprinkling of architecture (powerpc, x86, arm, mips) and filesystem (udf, xfs, reiserfs) changes. And some perf tooling. And we had some performance-tweaking of the new lockref support for ARM and s390. On the whole, nothing really appears very scary. Go forth and test, Linus --- Adrian Hunter (4): perf annotate: Fix objdump line parsing offset validation perf tools: Fix buildid cache handling of kallsyms with kcore perf tools: Fix compile with libelf without get_phdrnum perf machine: Fix path unpopulated in machine__create_modules() Al Viro (1): USB: Fix breakage in ffs_fs_mount() Alan Stern (4): USB: iMX21: accept very late isochronous URBs USB: UHCI: accept very late isochronous URBs USB: OHCI: accept very late isochronous URBs USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd Alex Deucher (13): drm/radeon: avoid UVD corruption on AGP cards using GPU gart drm/radeon: additional gcc fixes for radeon_atombios.c drm/radeon: fix missed variable sized access drm/radeon/dpm: fetch the max clk from voltage dep tables helper drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables drm/radeon: don't set default clocks for SI when DPM is disabled drm/radeon: disable tests/benchmarks if accel is disabled drm/radeon: add missing hdmi callbacks for rv6xx drm/radeon/cik: fix overflow in vram fetch drm/radeon: fix hdmi audio on DCE3.0/3.1 asics Alex Ivanov (1): drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2) Alexander Usyskin (1): mei: cancel stall timers in mei_reset Andi Kleen (1): perf symbols: Demangle cloned functions Andrew Morton (8): revert "memcg, vmscan: do not fall into reclaim-all pass too quickly" revert "memcg: track all children over limit in the root" revert "memcg, vmscan: do not attempt soft limit reclaim if it would not scan anything" revert "memcg: track children in soft limit excess to improve soft limit" revert "memcg: enhance memcg iterator to support predicates" revert "vmscan, memcg: do softlimit reclaim also for targeted reclaim" revert "memcg: get rid of soft-limit tree infrastructure" revert "memcg, vmscan: integrate soft reclaim tighter with zone shrinking code" Andrzej Hajda (1): video: of: display_timing: correct display-timings node finding Ard Biesheuvel (1): ARM: 7837/3: fix Thumb-2 bug in AES assembler code Arnaldo Carvalho de Melo (1): perf session: Check for SIGINT in more loops Ben Whitten (1): ALSA: hda - Add fixup for MacBook Air 6,1 and 6,2 with CS4208 codec Benjamin Herrenschmidt (4): powerpc/irq: Run softirqs off the top of the irq stack powerpc: Remove ksp_limit on ppc64 powerpc/zImage: make the "OF" wrapper support ePAPR boot powerpc/pseries: Do not start secondaries in Open Firmware Benson Leung (1): driver core : Fix use after free of dev->parent in device_shutdown Chew, Chiau Ee (1): i2c: designware: 10-bit addressing mode enabling if I2C_DYNAMIC_TAR_UPDATE is set Chris Wilson (1): drm/i915: Use a temporary va_list for two-pass string handling Christian Daudt (1): MAINTAINERS: update mach-bcm related email address Christian König (1): drm/radeon/uvd: lower msg buffer requirements on UVD3 Chuansheng Liu (1): kernel/reboot.c: re-enable the function of variable reboot_default Dan Carpenter (2): cpqarray: fix info leak in ida_locked_ioctl() cciss: fix info leak in cciss_ioctl32_passthru() Daniel Vetter (3): drm/i915/tv: clear adjusted_mode.flags drm/i915: preserve pipe A quirk in i9xx_set_pipeconf drm/i915: Fix up usage of SHRINK_STOP Dave Chinner (4): xfs: lock the AIL before removing the buffer item xfs: asserting lock not held during freeing not valid xfs: fix XFS_IOC_FREE_EOFBLOCKS definition xfs: log recovery lsn ordering needs uuid check Dave Jones (1): x86/reboot: Fix apparent cut-n-paste mistake in Dell reboot workaround David Ahern (2): perf trace: Add mmap2 handler perf tools: Explicitly add libdl dependency David Cohen (1): usb: dwc3: add support for Merrifield David Vrabel (2): xen/balloon: don't
Re: [PATCH] PCI: Workaround missing pci_set_master in pci drivers
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 make the code more robot and wade off problem for missing > >> pci_set_master in drivers. > > > > Petty spelling nit; feel free to ignore unless you need to respin the > > patch anyway > > > > s/robot/robost/ > > That's an oddly spelled nitpick "correction". Sorry, typed too quickly. :-( - Ted -- 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] perf fixes
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(): memory corruption (fast): > > 0x00ee0b10 *** > > Hmm, works for me. In fact I wrote it to fix a perf top issue. > > What does valgrind say? Here's the -fsanitize=address output instead: markus@x4 perf % perf top --stdio 2>&1 | asan_symbolize.py = ==24617== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x600cb638 at pc 0x7f2683fad79d bp 0x7fffbb8ec3b0 sp 0x7fffbb8ebb70 WRITE of size 9 at 0x600cb638 thread T0 #0 0x7f2683fad79c in __interceptor_strcpy ??:? #1 0x4e422c in strcpy /usr/include/bits/string3.h:104 #2 0x4ddeff in dso__load /usr/src/linux/tools/perf/util/symbol.c:1085 #3 0x509058 in map__load /usr/src/linux/tools/perf/util/map.c:159 #4 0x49fa6b in perf_event__preprocess_sample /usr/src/linux/tools/perf/util/event.c:762 #5 0x455fa0 in perf_event__process_sample /usr/src/linux/tools/perf/builtin-top.c:719 #6 0x45be8e in perf_top__mmap_read /usr/src/linux/tools/perf/builtin-top.c:870 #7 0x41f88d in run_builtin /usr/src/linux/tools/perf/perf.c:319 #8 0x41bc05 in run_argv /usr/src/linux/tools/perf/perf.c:376 #9 0x7f2682d41a74 in __libc_start_main /home/markus/glibc/csu/libc-start.c:269 #10 0x41e948 in _start /home/markus/glibc/csu/../sysdeps/x86_64/start.S:122 0x600cb63d is located 0 bytes to the right of 61-byte region [0x600cb600,0x600cb63d) allocated by thread T0 here: #0 0x7f2683fb6d6f in __interceptor_realloc ??:? #1 0x4e420f in dso__load_sym /usr/src/linux/tools/perf/util/symbol-elf.c:951 #2 0x4ddeff in dso__load /usr/src/linux/tools/perf/util/symbol.c:1085 #3 0x509058 in map__load /usr/src/linux/tools/perf/util/map.c:159 #4 0x49fa6b in perf_event__preprocess_sample /usr/src/linux/tools/perf/util/event.c:762 #5 0x455fa0 in perf_event__process_sample /usr/src/linux/tools/perf/builtin-top.c:719 #6 0x45be8e in perf_top__mmap_read /usr/src/linux/tools/perf/builtin-top.c:870 #7 0x41f88d in run_builtin /usr/src/linux/tools/perf/perf.c:319 #8 0x41bc05 in run_argv /usr/src/linux/tools/perf/perf.c:376 #9 0x7f2682d41a74 in __libc_start_main /home/markus/glibc/csu/libc-start.c:269 Shadow bytes around the buggy address: 0x0c019670: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c019680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c019690: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0196a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0196b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c0196c0: 00 00 00 00 00 00 00[05]fa fa fa fa fd fd fd fd 0x0c0196d0: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd 0x0c0196e0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x0c0196f0: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd 0x0c019700: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd 0x0c019710: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==24617== ABORTING And please note that cloned functions are demangled just fine on my machine even without your patch, e.g.: 10.61% libQtGui.so.4.8.5 [.] QFontEngineFT::stringToCMap(QChar const*, int, QGlyphLayout*, int*, QFlags) const [clone .part.20] -- 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: [PATCH] PCI: Workaround missing pci_set_master in pci drivers
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_master in drivers. > > Petty spelling nit; feel free to ignore unless you need to respin the > patch anyway > > s/robot/robost/ That's an oddly spelled nitpick "correction". If you really want to fix it, it's "robust" and "ward off problems". But it's too late now, and the wrong spelling and word choice is in the git tree and released in the -rc3 I just pushed out. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Workaround missing pci_set_master in pci drivers
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 you need to respin the patch anyway s/robot/robost/ Cheers, - Ted -- 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] printk: Check real user/group id for %pK
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 example with the setuid pppd application on Ubuntu 12.04:
$ head -1 /proc/kallsyms
T startup_32
$ pppd file /proc/kallsyms
pppd: In file /proc/kallsyms: unrecognized option 'c100'
This will only leak the pointer value from the first line, but other setuid
binaries may leak more information.
Fix this by adding a check that in addition to the current process having
CAP_SYSLOG, that effective user and group ids are equal to the real ids. If a
setuid binary reads the contents of a file which uses %pK then the pointer
values will be printed as NULL if the real user is unprivileged.
Signed-off-by: Ryan Mallon
---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..b1cd14d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1312,10 +1312,24 @@ char *pointer(const char *fmt, char *buf, char *end,
void *ptr,
spec.field_width = default_width;
return string(buf, end, "pK-error", spec);
}
- if (!((kptr_restrict == 0) ||
- (kptr_restrict == 1 &&
- has_capability_noaudit(current, CAP_SYSLOG
- ptr = NULL;
+
+ /*
+* If kptr_restrict is set to 2, then %pK always prints as
+* NULL. If it is set to 1, then only print the real pointer
+* value if the current proccess has CAP_SYSLOG and is running
+* with the same credentials it started with. We don't want
+* badly written setuid binaries being able to read the real
+* pointers on behalf of unprivileged users.
+*/
+ {
+ const struct cred *cred = current_cred();
+
+ if (kptr_restrict == 2 || (kptr_restrict == 1 &&
+(!has_capability_noaudit(current, CAP_SYSLOG) ||
+ !uid_eq(cred->euid, cred->uid) ||
+ !gid_eq(cred->egid, cred->gid
+ ptr = NULL;
+ }
break;
case 'N':
switch (fmt[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: [PATCH 2/2] vfs: Get rid of duplicate file_ops check in do_readv_writev()
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 completely. I have that done in local queue; will push to #for-next tonight. file->f_op should never be NULL, period. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ipv4:PATCH] Allow userspace to specify primary or secondary ip on interface
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 primary blade, the 'floating mangaement ip' follows it, > and we want any of our traffic originated from the primary blade source from > the 'floating management ip' for consistency. but in this case, since the > local > blade management ip is always the primary ip on the mangaement interface and > 'floating management ip' is always secondary, kernel always choose the primary > ip as source ip address. thus we would like to add the flexibility in kernel > to > allow us to specify which ip to be primary or secondary. You have the flexibility already. You can specify a specific source address ot use in routes. -- 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] introduce synchronize_sched_{enter,exit}()
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 pattern > Just so I'm clear to what you are trying to implement... This is to handle the case (as Paul said) to see changes to state by RCU and back again? That is, it isn't enough to see that the state changed to something (like SLOW MODE), but we also need a way to see it change back? With get_online_cpus(), we need to see the state where it changed to "performing hotplug" where holders need to go into the slow path, and then also see the state change to "no longe performing hotplug" and the holders now go back to fast path. Is this the rational for this email? Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] perf fixes
> 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 > *** Hmm, works for me. In fact I wrote it to fix a perf top issue. What does valgrind say? -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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 net-next] fib_trie: avoid a redundant bit judgement in inflate
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 message how you tested it. -- 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_64: add config options to optimize for newer AMD processors
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 kernel already. If it doesn't bring any performance improvement - and I don't want to rain on your parade but I think it won't, at least not enough to warrant a serious look - there's absolutely no reason to add it. But hey, I'm always open to surprises! So surprise me! :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] x86_64: add config options to optimize for newer AMD processors
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 a negative >> performance hit when used? > > Just having the option for no good reason at all is a no-no. 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 kernel already. Despite this I am still happy to benchmark it to provide some more concrete proof. -- 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_64: add config options to optimize for newer AMD processors
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 the option for no good reason at all is a no-no. > I will, however, do some intensive profiling over the next week and > get back to you about exact improvements. Just in the past few days of > using it, I have noticed much better response time in time sensitive > user-space code (mostly emulators and multimedia apps). Yes, we need concrete benchmark numbers from a kernel built with MK8 or even GENERIC vs one built with those new options, most likely with the one for the box you'll be running the benchmarks on. And no microbenchmarks please. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] x86_64: add config options to optimize for newer AMD processors
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.12-rc2. These provide noticeable improvements over the >> K8 config option, and allow the kernel to take full advantage of >> AMD specific instruction set extensions, such as ABM, LZCNT, and >> POPCNT. > > A patch like that keeps popping up every couple of months. Please > show us those noticeable improvements because the guy last time > failed to do so. > > And also, keep in mind that distro kernels are built with > CONFIG_GENERIC_CPU so CPU-specific kernels are used only by the > small percentage of people who actually do build their own > kernels. > > Thanks. > 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? I will, however, do some intensive profiling over the next week and get back to you about exact improvements. Just in the past few days of using it, I have noticed much better response time in time sensitive user-space code (mostly emulators and multimedia apps). -- 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] hpet: remove useless check if fixmem32 is NULL
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 eyes. Cc: Randy Dunlap Signed-off-by: Tomas Winkler Signed-off-by: Clemens Ladisch --- drivers/char/hpet.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c index ab8651d..d6568a6 100644 --- a/drivers/char/hpet.c +++ b/drivers/char/hpet.c @@ -971,8 +971,6 @@ static acpi_status hpet_resources(struct acpi_resource *res, void *data) struct acpi_resource_fixed_memory32 *fixmem32; fixmem32 = >data.fixed_memory32; - if (!fixmem32) - return AE_NO_MEMORY; hdp->hd_phys_address = fixmem32->address; hdp->hd_address = ioremap(fixmem32->address, -- 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] hpet: allow user controlled mmap for user processes
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.
This is a problem for distributions -- some users want the MMAP functionality
but it comes with a significant security risk. In an effort to mitigate this
risk, and due to the low number of users of the MMAP functionality, I've
introduced a kernel parameter, hpet_mmap_enable, that is required in order
to actually have the HPET MMAP exposed.
[v2]: Clemens suggested modifying the Kconfig help text and making the
default setting configurable.
[v3]: Fixed up Documentation and Kconfig entries, default now "Y"
[v4]: After testing, found that I need to modify CONFIG_HPET_MMAP_DEFAULT usage
[v5]: Fixed up Documentation, Kconfig entry, and log message [CL]
Signed-off-by: Prarit Bhargava
Acked-by: Matt Wilson
Signed-off-by: Clemens Ladisch
---
Documentation/kernel-parameters.txt |3 +++
drivers/char/Kconfig| 10 --
drivers/char/hpet.c | 24 ++--
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 539a236..6a7b656 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1064,6 +1064,9 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
VIA, nVidia)
verbose: show contents of HPET registers during setup
+ hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
+ registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
+
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 1421997..fa3243d 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -522,10 +522,16 @@ config HPET_MMAP
If you say Y here, user applications will be able to mmap
the HPET registers.
+config HPET_MMAP_DEFAULT
+ bool "Enable HPET MMAP access by default"
+ default y
+ depends on HPET_MMAP
+ help
In some hardware implementations, the page containing HPET
registers may also contain other things that shouldn't be
- exposed to the user. If this applies to your hardware,
- say N here.
+ exposed to the user. This option selects the default (if
+ kernel parameter hpet_mmap is not set) user access to the
+ registers for applications that require it.
config HANGCHECK_TIMER
tristate "Hangcheck timer"
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index d6568a6..964d002 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -367,12 +367,29 @@ static unsigned int hpet_poll(struct file *file,
poll_table * wait)
return 0;
}
+#ifdef CONFIG_HPET_MMAP
+#ifdef CONFIG_HPET_MMAP_DEFAULT
+static int hpet_mmap_enabled = 1;
+#else
+static int hpet_mmap_enabled = 0;
+#endif
+
+static __init int hpet_mmap_enable(char *str)
+{
+ get_option(, _mmap_enabled);
+ pr_info("HPET mmap %s\n", hpet_mmap_enabled ? "enabled" : "disabled");
+ return 1;
+}
+__setup("hpet_mmap", hpet_mmap_enable);
+
static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
{
-#ifdef CONFIG_HPET_MMAP
struct hpet_dev *devp;
unsigned long addr;
+ if (!hpet_mmap_enabled)
+ return -EACCES;
+
devp = file->private_data;
addr = devp->hd_hpets->hp_hpet_phys;
@@ -381,10 +398,13 @@ static int hpet_mmap(struct file *file, struct
vm_area_struct *vma)
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
return vm_iomap_memory(vma, addr, PAGE_SIZE);
+}
#else
+static int hpet_mmap(struct file *file, struct vm_area_struct *vma)
+{
return -ENOSYS;
-#endif
}
+#endif
static int hpet_fasync(int fd, struct file *file, int on)
{
--
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 tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks()
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 at 10:55:30AM +0800, Chen Gang wrote: > > > > Thank you for your whole work, firstly :-). > > > > And your suggestion about testing (in our discussion) is also valuable > > to me. > > > > I need start LTP in q4. After referenced your suggestion, my first step > > for using/learning LTP is not mainly for finding kernel issues, but for > > testing kernel (to improve my kernel testing efficiency). > > > > When I want to find issues by reading code, I will consider about LTP > > too (I will try to find issues which can be tested by LTP). > > Doing more testing will be good! You will probably need more tests > than just LTP, but you must of course start somewhere. > >>> > >>> Give more testing is good, but also mean more time resources cost. If > >>> spend the 'cost', also need get additional 'contributions' (not only > >>> prove an issue), or the 'efficiency' can not be 'acceptable'. > >>> > >>> When "I need more tests than just LTP", firstly I need perform this > >>> test, and then, also try to send "test case" to LTP (I guess, these > >>> kinds of mails are welcomed by LTP). > >>> > >>> And LTP is also a way to find kernel issues, although I will not mainly > >>> depend on it now (but maybe in future), it is better to familiar with it > >>> step by step. > >>> > >>> LTP (Linux Test Project) is one of main kernel mad user at downstream. > >>> Tool chain (GCC/Binutils) is one of kernel main mad tools at upstream. > >>> If we face to the whole kernel, suggest to use them. ;-) > >> > >> Yep, starting with just LTP is OK. But if by this time next year you > >> really should be using more than just LTP. > >> > > What I have done is trying to fully use other members contributions, not > trying to instead of them. > > > And the reason why I want/try to 'open' my 'ideas' to public: > > get more suggestions, and completions from other members. > > share my ideas, it can let other members provide more contributions (e.g. I > am glad, if find other members also try 'allmodconfig' on all architectures). > > If some members replicate me, I will save my current time resources and > devote them to another things (which also based on other members > contributions). > > > In my opinion: > > "Open and Share" are both important and urgent to everyone, although it may > not be noticed directly. Like "Air and Water" which God have blessed to > everyone. In a general sense, of course. In many specific cases, effective sharing can require quite a bit of preparation. For but one example, in Dipankar's and my case, it took about two years of work (mostly Dipankar's work) to get the initial implementation of RCU accepted into the Linux kernel. In your case, you can invest an average of three days per accepted patch if you are to achieve your goal of ten patches accepted per month (if I remember correctly). Of course, not every patch will be accepted, which reduces your per-patch time. For example, if 50% of your patches are accepted, you can invest an average of about 1.5 days per patch. Of course, investing in learning about test frameworks or specific kernel subsystems further reduces your time available per patch. But if you don't invest in your learning, you will be limited in what you can effectively contribute. This might be OK, for all I know. After all, in the 15 million lines of Linux kernel code, there is probably a very large number of point-problems waiting to be fixed. But suppose that you run out of easily found point problems? Or that you want to do something more wide-ranging than fixes for point problems? What can you do? Here are a few options. If you think more about it, I am sure that you can come up with others. 1. Put the ten-patches-per-month quota aside for a month (or two or three or whatever is required and appropriate). Spend this time studying a given kernel subsystem or a given test framework. (Which kernel subsystem? The best candidates would be those having bugs but no active maintainer, but which you have the hardware needed to adequately test.) 2. Add a review and/or test component to your monthly quota, so that a given patch could be substituted for by some number of Reviewed-by or Tested-by flags. Of course, this gives your a chicken-and-egg problem because you cannot adequately review or test without some understanding of the subsystem in question. (At least not efficiently enough to get enough Tested-by or Reviewed-by flags.) 3. Set aside a fixed amount of time each week (or each month) to
[PATCH] gpio: arizona: Use the of_node from the Arizona device
We need to use the of_node from the main Arizona device as that
holds our configuration.
Signed-off-by: Charles Keepax
---
drivers/gpio/gpio-arizona.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index a2bec3c..dceb5dc 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -109,6 +109,9 @@ static int arizona_gpio_probe(struct platform_device *pdev)
arizona_gpio->arizona = arizona;
arizona_gpio->gpio_chip = template_chip;
arizona_gpio->gpio_chip.dev = >dev;
+#ifdef CONFIG_OF_GPIO
+ arizona_gpio->gpio_chip.of_node = arizona->dev->of_node;
+#endif
switch (arizona->type) {
case WM5102:
--
1.7.2.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/
[ 02/17] net: usb: cdc_ether: Use wwan interface for Telit modules
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Fabio Porcedda
commit 0092820407901a0b2c4e343e85f96bb7abfcded1 upstream.
Signed-off-by: Fabio Porcedda
Acked-by: Oliver Neukum
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/usb/cdc_ether.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -615,6 +615,11 @@ static const struct usb_device_id produc
.bInterfaceProtocol = USB_CDC_PROTO_NONE,
.driver_info = (unsigned long)_info,
}, {
+ /* Telit modules */
+ USB_VENDOR_AND_INTERFACE_INFO(0x1bc7, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = (kernel_ulong_t) _info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) _info,
--
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/
[ 06/17] drm/radeon: fix LCD record parsing
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Alex Deucher commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream. If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/radeon/radeon_atombios.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1658,7 +1658,9 @@ struct radeon_encoder_atom_dig *radeon_a kfree(edid); } } - record += sizeof(ATOM_FAKE_EDID_PATCH_RECORD); + record += fake_edid_record->ucFakeEDIDLength ? + fake_edid_record->ucFakeEDIDLength + 2 : + sizeof(ATOM_FAKE_EDID_PATCH_RECORD); break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; -- 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/
[ 08/17] drm/radeon: fix resume on some rs4xx boards (v2)
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream.
Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
some boards on resume. The systems seem to work fine
without touching this bit so leave it as is.
v2: read-modify-write the GART_INDEX_REG_EN bit.
I suspect the problem is that we are losing the other
settings in the register.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=52952
Reported-by: Ondrej Zary
Tested-by: Daniel Tobias
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/radeon/rs400.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -174,10 +174,13 @@ int rs400_gart_enable(struct radeon_devi
/* FIXME: according to doc we should set HIDE_MMCFG_BAR=0,
* AGPMODE30=0 & AGP30ENHANCED=0 in NB_CNTL */
if ((rdev->family == CHIP_RS690) || (rdev->family == CHIP_RS740)) {
- WREG32_MC(RS480_MC_MISC_CNTL,
- (RS480_GART_INDEX_REG_EN | RS690_BLOCK_GFX_D3_EN));
+ tmp = RREG32_MC(RS480_MC_MISC_CNTL);
+ tmp |= RS480_GART_INDEX_REG_EN | RS690_BLOCK_GFX_D3_EN;
+ WREG32_MC(RS480_MC_MISC_CNTL, tmp);
} else {
- WREG32_MC(RS480_MC_MISC_CNTL, RS480_GART_INDEX_REG_EN);
+ tmp = RREG32_MC(RS480_MC_MISC_CNTL);
+ tmp |= RS480_GART_INDEX_REG_EN;
+ WREG32_MC(RS480_MC_MISC_CNTL, tmp);
}
/* Enable gart */
WREG32_MC(RS480_AGP_ADDRESS_SPACE_SIZE, (RS480_GART_EN | size_reg));
--
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/
[ 10/17] SCSI: iscsi: dont hang in endless loop if no targets present
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Sasha Levin
commit 46a7c17d26967922092f3a8291815ffb20f6cabe upstream.
iscsi_if_send_reply() may return -ESRCH if there were no targets to send
data to. Currently we're ignoring this value and looping in attempt to do it
over and over, which will usually lead in a hung task like this one:
[ 4920.817298] INFO: task trinity:9074 blocked for more than 120 seconds.
[ 4920.818527] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 4920.819982] trinity D 5504 9074 2756 0x0004
[ 4920.825374] 880003961a98 0086 881aa000
881aa000
[ 4920.826791] 001d4340 880003961fd8 88000396
001d4340
[ 4920.828241] 001d4340 001d4340 880003961fd8
001d4340
[ 4920.833231]
[ 4920.833519] Call Trace:
[ 4920.834010] [] schedule+0x3a/0x50
[ 4920.834953] [] __mutex_lock_common+0x209/0x5b0
[ 4920.836226] [] ? iscsi_if_rx+0x2d/0x990
[ 4920.837281] [] ? sched_clock+0x13/0x20
[ 4920.838305] [] ? iscsi_if_rx+0x2d/0x990
[ 4920.839336] [] mutex_lock_nested+0x40/0x50
[ 4920.840423] [] iscsi_if_rx+0x2d/0x990
[ 4920.841434] [] ? sub_preempt_count+0x9d/0xd0
[ 4920.842548] [] ? _raw_read_unlock+0x30/0x60
[ 4920.843666] [] netlink_unicast+0x1ae/0x1f0
[ 4920.844751] [] netlink_sendmsg+0x227/0x350
[ 4920.845850] [] ? sock_update_netprioidx+0xdd/0x1b0
[ 4920.847060] [] ? sock_update_netprioidx+0x52/0x1b0
[ 4920.848276] [] sock_aio_write+0x166/0x180
[ 4920.849348] [] ? get_parent_ip+0x11/0x50
[ 4920.850428] [] do_sync_write+0xda/0x120
[ 4920.851465] [] ? sub_preempt_count+0x9d/0xd0
[ 4920.852579] [] ? get_parent_ip+0x11/0x50
[ 4920.853608] [] ? security_file_permission+0x27/0xb0
[ 4920.854821] [] vfs_write+0x16c/0x180
[ 4920.855781] [] sys_write+0x4f/0xa0
[ 4920.856798] [] system_call_fastpath+0x16/0x1b
[ 4920.877487] 1 lock held by trinity/9074:
[ 4920.878239] #0: (rx_queue_mutex){+.+...}, at: []
iscsi_if_rx+0x2d/0x990
[ 4920.880005] Kernel panic - not syncing: hung_task: blocked tasks
Signed-off-by: Sasha Levin
Acked-by: Mike Christie
Signed-off-by: James Bottomley
Cc: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1747,7 +1747,7 @@ iscsi_if_rx(struct sk_buff *skb)
break;
err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
- } while (err < 0 && err != -ECONNREFUSED);
+ } while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}
mutex_unlock(_queue_mutex);
--
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/
[ 01/17] Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()"
3.0-stable review patch. If anyone has any objections, please let me know. -- From: Greg Kroah-Hartman This reverts commit b23270416da409bd4e637a5acbe31a1126235fb6 which is commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec. Michal writes: Mainline commit f6e80abe was introduced in v3.7-rc2 as a follow-up fix to commit edfee033 sctp: check src addr when processing SACK to update transport state (from v3.7-rc1) which changed the interpretation of third argument to sctp_cmd_process_sack() and sctp_outq_sack(). But as commit edfee033 has never been backported to stable branches, backport of commit f6e80abe actually breaks the code rather than fixing it. Reported-by: Michal Kubecek Cc: Zijie Pan Cc: Nicolas Dichtel Cc: Vlad Yasevich Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/sctp/sm_sideeffect.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/net/sctp/sm_sideeffect.c +++ b/net/sctp/sm_sideeffect.c @@ -1604,9 +1604,8 @@ static int sctp_cmd_interpreter(sctp_eve asoc->outqueue.outstanding_bytes; sackh.num_gap_ack_blocks = 0; sackh.num_dup_tsns = 0; - chunk->subh.sack_hdr = sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, - SCTP_CHUNK(chunk)); + SCTP_SACKH()); break; case SCTP_CMD_DISCARD_PACKET: -- 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/
[ 07/17] drm/radeon: update line buffer allocation for dce4.1/5
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce4.1/5 asics.
Based on an initial fix from:
Jay Cornwall
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/radeon/evergreen.c | 25 +
drivers/gpu/drm/radeon/evergreend.h |4
2 files changed, 25 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -419,7 +419,8 @@ static u32 evergreen_line_buffer_adjust(
struct drm_display_mode *mode,
struct drm_display_mode *other_mode)
{
- u32 tmp;
+ u32 tmp, buffer_alloc, i;
+ u32 pipe_offset = radeon_crtc->crtc_id * 0x20;
/*
* Line Buffer Setup
* There are 3 line buffers, each one shared by 2 display controllers.
@@ -442,18 +443,34 @@ static u32 evergreen_line_buffer_adjust(
* non-linked crtcs for maximum line buffer allocation.
*/
if (radeon_crtc->base.enabled && mode) {
- if (other_mode)
+ if (other_mode) {
tmp = 0; /* 1/2 */
- else
+ buffer_alloc = 1;
+ } else {
tmp = 2; /* whole */
- } else
+ buffer_alloc = 2;
+ }
+ } else {
tmp = 0;
+ buffer_alloc = 0;
+ }
/* second controller of the pair uses second half of the lb */
if (radeon_crtc->crtc_id % 2)
tmp += 4;
WREG32(DC_LB_MEMORY_SPLIT + radeon_crtc->crtc_offset, tmp);
+ if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
+ WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+ DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+ for (i = 0; i < rdev->usec_timeout; i++) {
+ if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset) &
+ DMIF_BUFFERS_ALLOCATED_COMPLETED)
+ break;
+ udelay(1);
+ }
+ }
+
if (radeon_crtc->base.enabled && mode) {
switch (tmp) {
case 0:
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -450,6 +450,10 @@
# define LATENCY_LOW_WATERMARK(x) ((x) << 0)
# define LATENCY_HIGH_WATERMARK(x) ((x) << 16)
+#definePIPE0_DMIF_BUFFER_CONTROL 0x0ca0
+# define DMIF_BUFFERS_ALLOCATED(x) ((x) << 0)
+# define DMIF_BUFFERS_ALLOCATED_COMPLETED (1 << 4)
+
#define IH_RB_CNTL0x3e00
# define IH_RB_ENABLE (1 << 0)
# define IH_IB_SIZE(x) ((x) << 1) /* log2 */
--
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/
[ 13/17] perf: Fix perf_cgroup_switch for sw-events
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit 95cf59ea72331d0093010543b8951bb43f262cac upstream.
Jiri reported that he could trigger the WARN_ON_ONCE() in
perf_cgroup_switch() using sw-events. This is because sw-events share
a cpuctx with multiple PMUs.
Use the ->unique_pmu pointer to limit the pmu iteration to unique
cpuctx instances.
Reported-and-Tested-by: Jiri Olsa
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-so7wi2zf3jjzrwcutm2mk...@git.kernel.org
Signed-off-by: Ingo Molnar
Cc: Li Zefan
Signed-off-by: Greg Kroah-Hartman
---
kernel/events/core.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -342,6 +342,8 @@ void perf_cgroup_switch(struct task_stru
list_for_each_entry_rcu(pmu, , entry) {
cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
+ if (cpuctx->unique_pmu != pmu)
+ continue; /* ensure we process each cpuctx once */
perf_pmu_disable(cpuctx->ctx.pmu);
@@ -365,9 +367,10 @@ void perf_cgroup_switch(struct task_stru
if (mode & PERF_CGROUP_SWIN) {
WARN_ON_ONCE(cpuctx->cgrp);
- /* set cgrp before ctxsw in to
-* allow event_filter_match() to not
-* have to pass task around
+ /*
+* set cgrp before ctxsw in to allow
+* event_filter_match() to not have to pass
+* task around
*/
cpuctx->cgrp = perf_cgroup_from_task(task);
cpu_ctx_sched_in(cpuctx, EVENT_ALL, task);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 11/17] cgroup: fail if monitored file and event_control are in different cgroup
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Li Zefan
commit f169007b2773f285e098cb84c74aac0154d65ff7 upstream.
If we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control
of cgroup B, then we won't get memory usage notification from A but B!
What's worse, if A and B are in different mount hierarchy, we'll end up
accessing NULL pointer!
Disallow this kind of invalid usage.
Signed-off-by: Li Zefan
Acked-by: Kirill A. Shutemov
Signed-off-by: Tejun Heo
Cc: Weng Meiling
Signed-off-by: Greg Kroah-Hartman
---
kernel/cgroup.c | 11 +++
1 file changed, 11 insertions(+)
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3498,6 +3498,7 @@ static int cgroup_write_event_control(st
const char *buffer)
{
struct cgroup_event *event = NULL;
+ struct cgroup *cgrp_cfile;
unsigned int efd, cfd;
struct file *efile = NULL;
struct file *cfile = NULL;
@@ -3552,6 +3553,16 @@ static int cgroup_write_event_control(st
goto fail;
}
+ /*
+* The file to be monitored must be in the same cgroup as
+* cgroup.event_control is.
+*/
+ cgrp_cfile = __d_cgrp(cfile->f_dentry->d_parent);
+ if (cgrp_cfile != cgrp) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
if (!event->cft->register_event || !event->cft->unregister_event) {
ret = -EINVAL;
goto fail;
--
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/
[ 12/17] perf: Clarify perf_cpu_context::active_pmu usage by renaming it to ::unique_pmu
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit 3f1f33206c16c7b3839d71372bc2ac3f305aa802 upstream.
Stephane thought the perf_cpu_context::active_pmu name confusing and
suggested using 'unique_pmu' instead.
This pointer is a pointer to a 'random' pmu sharing the cpuctx
instance, therefore limiting a for_each_pmu loop to those where
cpuctx->unique_pmu matches the pmu we get a loop over unique cpuctx
instances.
Suggested-by: Stephane Eranian
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-kxyjqpfj2fn9gt7kwu5ag...@git.kernel.org
Signed-off-by: Ingo Molnar
Cc: Li Zefan
Signed-off-by: Greg Kroah-Hartman
---
include/linux/perf_event.h |2 +-
kernel/events/core.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -939,7 +939,7 @@ struct perf_cpu_context {
int exclusive;
struct list_headrotation_list;
int jiffies_interval;
- struct pmu *active_pmu;
+ struct pmu *unique_pmu;
struct perf_cgroup *cgrp;
};
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4579,7 +4579,7 @@ static void perf_event_task_event(struct
rcu_read_lock();
list_for_each_entry_rcu(pmu, , entry) {
cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
- if (cpuctx->active_pmu != pmu)
+ if (cpuctx->unique_pmu != pmu)
goto next;
perf_event_task_ctx(>ctx, task_event);
@@ -4725,7 +4725,7 @@ static void perf_event_comm_event(struct
rcu_read_lock();
list_for_each_entry_rcu(pmu, , entry) {
cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
- if (cpuctx->active_pmu != pmu)
+ if (cpuctx->unique_pmu != pmu)
goto next;
perf_event_comm_ctx(>ctx, comm_event);
@@ -4921,7 +4921,7 @@ got_name:
rcu_read_lock();
list_for_each_entry_rcu(pmu, , entry) {
cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
- if (cpuctx->active_pmu != pmu)
+ if (cpuctx->unique_pmu != pmu)
goto next;
perf_event_mmap_ctx(>ctx, mmap_event,
vma->vm_flags & VM_EXEC);
@@ -5947,8 +5947,8 @@ static void update_pmu_context(struct pm
cpuctx = per_cpu_ptr(pmu->pmu_cpu_context, cpu);
- if (cpuctx->active_pmu == old_pmu)
- cpuctx->active_pmu = pmu;
+ if (cpuctx->unique_pmu == old_pmu)
+ cpuctx->unique_pmu = pmu;
}
}
@@ -6080,7 +6080,7 @@ skip_type:
cpuctx->ctx.pmu = pmu;
cpuctx->jiffies_interval = 1;
INIT_LIST_HEAD(>rotation_list);
- cpuctx->active_pmu = pmu;
+ cpuctx->unique_pmu = pmu;
}
got_cpu_context:
--
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/
[ 06/22] HID: zeroplus: validate output report details
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit 78214e81a1bf43740ce89bb5efda78eac2f8ef83 upstream.
The zeroplus HID driver was not checking the size of allocated values
in fields it used. A HID device could send a malicious output report
that would cause the driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005
...
[ 1466.243173] BUG kmalloc-192 (Tainted: GW ): Redzone overwritten
CVE-2013-2889
Signed-off-by: Kees Cook
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-zpff.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
--- a/drivers/hid/hid-zpff.c
+++ b/drivers/hid/hid-zpff.c
@@ -70,21 +70,13 @@ static int zpff_init(struct hid_device *
struct hid_report *report;
struct hid_input *hidinput = list_entry(hid->inputs.next,
struct hid_input, list);
- struct list_head *report_list =
- >report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
- int error;
+ int i, error;
- if (list_empty(report_list)) {
- hid_err(hid, "no output report found\n");
- return -ENODEV;
- }
-
- report = list_entry(report_list->next, struct hid_report, list);
-
- if (report->maxfield < 4) {
- hid_err(hid, "not enough fields in report\n");
- return -ENODEV;
+ for (i = 0; i < 4; i++) {
+ report = hid_validate_values(hid, HID_OUTPUT_REPORT, 0, i, 1);
+ if (!report)
+ return -ENODEV;
}
zpff = kzalloc(sizeof(struct zpff_device), GFP_KERNEL);
--
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/
[ 05/22] HID: provide a helper for validating hid reports
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit 331415ff16a12147d57d5c953f3a961b7ede348b upstream.
Many drivers need to validate the characteristics of their HID report
during initialization to avoid misusing the reports. This adds a common
helper to perform validation of the report exisitng, the field existing,
and the expected number of values within the field.
Signed-off-by: Kees Cook
Reviewed-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-core.c | 58 +
include/linux/hid.h|4 +++
2 files changed, 62 insertions(+)
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -821,6 +821,64 @@ static int search(__s32 *array, __s32 va
return -1;
}
+static const char * const hid_report_names[] = {
+ "HID_INPUT_REPORT",
+ "HID_OUTPUT_REPORT",
+ "HID_FEATURE_REPORT",
+};
+/**
+ * hid_validate_values - validate existing device report's value indexes
+ *
+ * @device: hid device
+ * @type: which report type to examine
+ * @id: which report ID to examine (0 for first)
+ * @field_index: which report field to examine
+ * @report_counts: expected number of values
+ *
+ * Validate the number of values in a given field of a given report, after
+ * parsing.
+ */
+struct hid_report *hid_validate_values(struct hid_device *hid,
+ unsigned int type, unsigned int id,
+ unsigned int field_index,
+ unsigned int report_counts)
+{
+ struct hid_report *report;
+
+ if (type > HID_FEATURE_REPORT) {
+ hid_err(hid, "invalid HID report type %u\n", type);
+ return NULL;
+ }
+
+ if (id >= HID_MAX_IDS) {
+ hid_err(hid, "invalid HID report id %u\n", id);
+ return NULL;
+ }
+
+ /*
+* Explicitly not using hid_get_report() here since it depends on
+* ->numbered being checked, which may not always be the case when
+* drivers go to access report values.
+*/
+ report = hid->report_enum[type].report_id_hash[id];
+ if (!report) {
+ hid_err(hid, "missing %s %u\n", hid_report_names[type], id);
+ return NULL;
+ }
+ if (report->maxfield <= field_index) {
+ hid_err(hid, "not enough fields in %s %u\n",
+ hid_report_names[type], id);
+ return NULL;
+ }
+ if (report->field[field_index]->report_count < report_counts) {
+ hid_err(hid, "not enough values in %s %u field %u\n",
+ hid_report_names[type], id, field_index);
+ return NULL;
+ }
+ return report;
+}
+EXPORT_SYMBOL_GPL(hid_validate_values);
+
/**
* hid_match_report - check if driver's raw_event should be called
*
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -737,6 +737,10 @@ void hid_output_report(struct hid_report
struct hid_device *hid_allocate_device(void);
struct hid_report *hid_register_report(struct hid_device *device, unsigned
type, unsigned id);
int hid_parse_report(struct hid_device *hid, __u8 *start, unsigned size);
+struct hid_report *hid_validate_values(struct hid_device *hid,
+ unsigned int type, unsigned int id,
+ unsigned int field_index,
+ unsigned int report_counts);
int hid_check_keys_pressed(struct hid_device *hid);
int hid_connect(struct hid_device *hid, unsigned int connect_mask);
void hid_disconnect(struct hid_device *hid);
--
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/
