* [PATCH 1/2] ASoC: Add CS4271 codec support
From: Timur Tabi @ 2010-10-07 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CAD16A5.1090501@bluewatersys.com>
Ryan Mallon wrote:
> + * For setups with variable MCLKs, pass 0 as 'freq' argument. This will cause
> + * theoretically possible sample rates to be enabled. Call it again with a
> + * proper value set one the external clock is set (most probably you would do
> + * that from a machine's driver 'hw_param' hook.
If you're going to copy/paste parts of my driver verbatim into yours, you should
put something like this in the comments:
Based on the CS4270 driver by Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: Add CS4271 codec support
From: Timur Tabi @ 2010-10-07 21:46 UTC (permalink / raw)
To: Ryan Mallon
Cc: alsa-devel@alsa-project.org, Mark Brown, linux-arm-kernel,
Liam Girdwood
In-Reply-To: <4CAD16A5.1090501@bluewatersys.com>
Ryan Mallon wrote:
> + * For setups with variable MCLKs, pass 0 as 'freq' argument. This will cause
> + * theoretically possible sample rates to be enabled. Call it again with a
> + * proper value set one the external clock is set (most probably you would do
> + * that from a machine's driver 'hw_param' hook.
If you're going to copy/paste parts of my driver verbatim into yours, you should
put something like this in the comments:
Based on the CS4270 driver by Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Mario Limonciello @ 2010-10-07 21:45 UTC (permalink / raw)
To: Matthew Garrett
Cc: Dmitry Torokhov, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007214212.GA2010@srcf.ucam.org>
Matthew:
On Thu, Oct 7, 2010 at 16:42, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, Oct 07, 2010 at 04:41:12PM -0500, Mario Limonciello wrote:
>
>> All Dell laptops are /supposed/ to adhere to the specification in
>> question. Unfortunately, not all machines are tested with Linux
>> during their development and on the OS they ship with that
>> functionality isn't always used in that specific way for rfkill.
>
> I don't understand this. You know which code is broken - surely you're
> able to determine which products shipped with BIOSes derived from the
> broken code?
>
> --
> Matthew Garrett | mjg59@srcf.ucam.org
>
Not all product's BIOS are developed in-house. The ones that are, yes
it quite possible to identify. Matter of fact, this issue tends to
not exist on the in-house developed BIOS codebase.
--
Mario Limonciello
superm1@gmail.com
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Rafael J. Wysocki @ 2010-10-07 21:43 UTC (permalink / raw)
To: Sameer Nanda
Cc: Greg KH, lenb, stefan.bader, brad.figg, apw, linux-acpi,
linux-kernel
In-Reply-To: <AANLkTimD5Vrjp8tB6crdaOdS-=LYV+JZL0tCLLcruFGu@mail.gmail.com>
On Thursday, October 07, 2010, Sameer Nanda wrote:
> On Thu, Oct 7, 2010 at 12:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Thursday, October 07, 2010, Sameer Nanda wrote:
> >> (resending as plain text, sorry if you got dupe messages)
> >>
> >> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> >> > On Wed, Oct 06, 2010 at 04:15:19PM -0700, Sameer Nanda wrote:
> >> >> Read the TSC upon resuming and print it out. This is useful
> >> >> in helping figure out amount of time spent in the BIOS when
> >> >> resuming from suspend.
> >> >>
> >> >> Change-Id: I1d6a32bd62421becddecd152d561763e5f3e1101
> >> >
> >> > What is this tag for? I don't think it matches anything the kernel
> >> > community wants, do you?
> >>
> >> Yeah, its not needed. Let me resubmit the patch without this tag.
> >>
> >> >
> >> > And are you always going to be printing this out? Why do we want to
> >> > know this every time?
> >>
> >> Yes, every time. This helps track variance in BIOS resume times
> >> within a single boot.
> >>
> >> >
> >> >> Signed-off-by: Sameer Nanda <snanda@chromium.org>
> >> >> ---
> >> >> drivers/acpi/sleep.c | 4 ++++
> >> >> 1 files changed, 4 insertions(+), 0 deletions(-)
> >> >>
> >> >> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> >> >> index c0fed2e..f0588fa 100644
> >> >> --- a/drivers/acpi/sleep.c
> >> >> +++ b/drivers/acpi/sleep.c
> >> >> @@ -214,6 +214,7 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
> >> >> acpi_status status = AE_OK;
> >> >> unsigned long flags = 0;
> >> >> u32 acpi_state = acpi_target_sleep_state;
> >> >> + u64 tsc;
> >> >>
> >> >> ACPI_FLUSH_CPU_CACHE();
> >> >>
> >> >> @@ -235,6 +236,9 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
> >> >>
> >> >> case ACPI_STATE_S3:
> >> >> do_suspend_lowlevel();
> >> >> + rdtscll(tsc);
> >> >> + printk(KERN_INFO "TSC at resume: %llu\n",
> >> >> + (unsigned long long)tsc);
> >> >
> >> > How long does this take, will it slow down resume?
> >>
> >> The impact is ~10us (as measured on an Intel Atom N455 @ 1.66Ghz).
> >> Given that resume time is currently of the order of 1sec, its in the
> >> noise range.
> >
> > Do I think correctly that it assumes the TSC will be updated in the sleep state?
>
> No, it actually banks on TSC not being updated while the system is in S3 state.
> Theory here being that upon resuming from S3, the CPU gets reset and so TSC
> starts counting up from 0. Therefore, reading the TSC value in the kernel upon
> resuming gives the number of cycles spent in the BIOS in resume path.
Ah that. OK, that's more clear now.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Rafael J. Wysocki @ 2010-10-07 21:44 UTC (permalink / raw)
To: Greg KH
Cc: Sameer Nanda, lenb, stefan.bader, brad.figg, apw, linux-acpi,
linux-kernel
In-Reply-To: <20101007181536.GA24811@suse.de>
On Thursday, October 07, 2010, Greg KH wrote:
> On Thu, Oct 07, 2010 at 11:05:21AM -0700, Sameer Nanda wrote:
> > On Thu, Oct 7, 2010 at 10:46 AM, Greg KH <gregkh@suse.de> wrote:
> > > On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
> > >> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> > >> > And are you always going to be printing this out? Why do we want to
> > >> > know this every time?
> > >> >
> > >>
> > >> Yes, every time. This helps track variance in BIOS resume times within a
> > >> single boot.
> > >
> > > Is that really something that users can do something about?
> >
> > Aside from complaining to the BIOS vendors, no :)
>
> Then I would not recommend adding this patch, as it is irrelevant for
> 99.9999% of all Linux users.
It may be somewhat useful, but the rdtscll() call seems to be x86-specific, in
which case it shouldn't be used at this place.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Greg KH @ 2010-10-07 21:41 UTC (permalink / raw)
To: rklein
Cc: jic23, joe, achew, olof, linux-i2c, linux-kernel, linux-iio,
ldewangan
In-Reply-To: <1286480883-25589-1-git-send-email-rklein@nvidia.com>
On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein@nvidia.com wrote:
> From: Rhyland Klein <rklein@nvidia.com>
>
> adding support for the ISL 29018 ambient light and proximity sensor.
>
> Addressed comments from reviews by Jonathan Cameron and Joe Perches
> * Removed some excess dbg prints that only printed function name
> * Renamed some properties to make them more descriptive
> * Added a property to list available adc resolutions
> * Defined arrays for resolutions/ranges as static const
> * Change loops initialization to memset for extensibility.
> * used sizeof() instead of ARRAY_SIZE() to be safer
> * Added a property to list available adc ranges
>
> Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Too bad no one actually compiled this driver:
CC [M] drivers/staging/iio/light/isl29018.o
drivers/staging/iio/light/isl29018.c:420:8: error: ‘show_prox_infrared_suppression’ undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:433:1: error: ‘iio_dev_attr_range_available’ undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:435:1: error: ‘iio_dev_attr_adc_resolution_available’ undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c: In function ‘isl29018_chip_init’:
drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable ‘i’
drivers/staging/iio/light/isl29018.c: At top level:
drivers/staging/iio/light/isl29018.c:350:16: warning: ‘show_prox_infrared_supression’ defined but not used
drivers/staging/iio/light/isl29018.c:416:1: warning: ‘iio_const_attr_range_available’ defined but not used
drivers/staging/iio/light/isl29018.c:417:1: warning: ‘iio_const_attr_adc_resolution_available’ defined but not used
make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
make[1]: *** [drivers/staging/iio/light] Error 2
make: *** [_module_drivers/staging/iio] Error 2
Please fix this up before resending it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Greg KH @ 2010-10-07 21:41 UTC (permalink / raw)
To: rklein
Cc: jic23, joe, achew, olof, linux-i2c, linux-kernel, linux-iio,
ldewangan
In-Reply-To: <1286480883-25589-1-git-send-email-rklein@nvidia.com>
On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein@nvidia.com wrote:
> From: Rhyland Klein <rklein@nvidia.com>
>=20
> adding support for the ISL 29018 ambient light and proximity sensor.
>=20
> Addressed comments from reviews by Jonathan Cameron and Joe Perches
> * Removed some excess dbg prints that only printed function name
> * Renamed some properties to make them more descriptive
> * Added a property to list available adc resolutions
> * Defined arrays for resolutions/ranges as static const
> * Change loops initialization to memset for extensibility.
> * used sizeof() instead of ARRAY_SIZE() to be safer
> * Added a property to list available adc ranges
>=20
> Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Too bad no one actually compiled this driver:
CC [M] drivers/staging/iio/light/isl29018.o
drivers/staging/iio/light/isl29018.c:420:8: error: =E2=80=98show_prox_i=
nfrared_suppression=E2=80=99 undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:433:1: error: =E2=80=98iio_dev_att=
r_range_available=E2=80=99 undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:435:1: error: =E2=80=98iio_dev_att=
r_adc_resolution_available=E2=80=99 undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c: In function =E2=80=98isl29018_chi=
p_init=E2=80=99:
drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable =E2=
=80=98i=E2=80=99
drivers/staging/iio/light/isl29018.c: At top level:
drivers/staging/iio/light/isl29018.c:350:16: warning: =E2=80=98show_pro=
x_infrared_supression=E2=80=99 defined but not used
drivers/staging/iio/light/isl29018.c:416:1: warning: =E2=80=98iio_const=
_attr_range_available=E2=80=99 defined but not used
drivers/staging/iio/light/isl29018.c:417:1: warning: =E2=80=98iio_const=
_attr_adc_resolution_available=E2=80=99 defined but not used
make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
make[1]: *** [drivers/staging/iio/light] Error 2
make: *** [_module_drivers/staging/iio] Error 2
Please fix this up before resending it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 21:41 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <20101007223819.46246716@lxorguk.ukuu.org.uk>
On Thu, 2010-10-07 at 22:38 +0100, Alan Cox wrote:
> > Your making too many assumptions .. You might be able to modify the
> > kernel, and not the userspace. So you couldn't tweak the device
> > creation .. It's much easier in the server world ..
>
> Spare me the embedded is different lecture. It's not. In fact it's
> usually easier because the environment you are testing is usually
> standalone, doesn't cause a million dollar an hour downtime if you get it
> wrong and was designed for debug/test so actually has a jtag port.
fair enough, it's hard for both of us.
> If you can modify the file system you can make /dev/ttyS0 the major/minor
> of the jtag port.
>
> If you can load anything in front of the userspace you can rename the
> device/move it
>
> So I find your example case fictional. In fact the only time I can see
> you having a box so tightly locked up you can only tweak the kernel is
> jailbreaking it, in which case you are such a fringe usage case and
> technically competent that you can just do custom patches as you'll be
> doing anyway for other bits.
There's lots of other situations that can come up. You can't in anyway
say that there is some certain set of situations where you'll always
have X, Y, and Z.. There have been enough strange situations that I
don't think it's right for you or me to assume we just know what they
all are.
> > > We've said no over a period of about ten years to a lot of attempts to
> > > just borrow the ttyS0 range. If we'd said yes it would have been a
> > > complete mess by now.
> > >
> > > So the answer is no.
> >
> > Nothing can be unilateral, there's always room for exceptions. You
> > should say something more like "it's possible, but unlikely".
>
> This argument gets regurgitated every so often and nobody has yet
> provided a plausable reason to make a nasty mess.
There's plenty of nasty messes in the kernel, "they" must have had some
justification ..
> Either way I would suggest the path forward is
>
> - Look at the blackfin jtag using tty_port alone and see if it looks
> cleaner
Yeah ..
> - Fix the bugs noted
Check,
> - Submit a driver that uses the existing allocated jtag major/minor only
The driver does this already. It uses ttyJ* by default, and ttyS is an
option ..
> and then have a debate about ttyS0 hackery separately.
Fine with me..
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Matthew Garrett @ 2010-10-07 21:42 UTC (permalink / raw)
To: Mario Limonciello
Cc: Dmitry Torokhov, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <AANLkTinL9UckjiQGmMJ_NENPp9XxFHRdvTje_V46LPQ+@mail.gmail.com>
On Thu, Oct 07, 2010 at 04:41:12PM -0500, Mario Limonciello wrote:
> All Dell laptops are /supposed/ to adhere to the specification in
> question. Unfortunately, not all machines are tested with Linux
> during their development and on the OS they ship with that
> functionality isn't always used in that specific way for rfkill.
I don't understand this. You know which code is broken - surely you're
able to determine which products shipped with BIOSes derived from the
broken code?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Greg KH @ 2010-10-07 21:41 UTC (permalink / raw)
To: rklein-DDmLM1+adcrQT0dZR+AlfA
Cc: jic23-KWPb1pKIrIJaa/9Udqfwiw, joe-6d6DIl74uiNBDgjK7y7TUQ,
achew-DDmLM1+adcrQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
ldewangan-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1286480883-25589-1-git-send-email-rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org wrote:
> From: Rhyland Klein <rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> adding support for the ISL 29018 ambient light and proximity sensor.
>
> Addressed comments from reviews by Jonathan Cameron and Joe Perches
> * Removed some excess dbg prints that only printed function name
> * Renamed some properties to make them more descriptive
> * Added a property to list available adc resolutions
> * Defined arrays for resolutions/ranges as static const
> * Change loops initialization to memset for extensibility.
> * used sizeof() instead of ARRAY_SIZE() to be safer
> * Added a property to list available adc ranges
>
> Signed-off-by: Rhyland Klein <rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Acked-by: Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>
Too bad no one actually compiled this driver:
CC [M] drivers/staging/iio/light/isl29018.o
drivers/staging/iio/light/isl29018.c:420:8: error: ‘show_prox_infrared_suppression’ undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:433:1: error: ‘iio_dev_attr_range_available’ undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c:435:1: error: ‘iio_dev_attr_adc_resolution_available’ undeclared here (not in a function)
drivers/staging/iio/light/isl29018.c: In function ‘isl29018_chip_init’:
drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable ‘i’
drivers/staging/iio/light/isl29018.c: At top level:
drivers/staging/iio/light/isl29018.c:350:16: warning: ‘show_prox_infrared_supression’ defined but not used
drivers/staging/iio/light/isl29018.c:416:1: warning: ‘iio_const_attr_range_available’ defined but not used
drivers/staging/iio/light/isl29018.c:417:1: warning: ‘iio_const_attr_adc_resolution_available’ defined but not used
make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
make[1]: *** [drivers/staging/iio/light] Error 2
make: *** [_module_drivers/staging/iio] Error 2
Please fix this up before resending it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Mario Limonciello @ 2010-10-07 21:41 UTC (permalink / raw)
To: Matthew Garrett
Cc: Dmitry Torokhov, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007213754.GA1896@srcf.ucam.org>
Matthew:
On Thu, Oct 7, 2010 at 16:37, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, Oct 07, 2010 at 02:30:28PM -0700, Dmitry Torokhov wrote:
>
>> We have this strategy for bunch of input stuff (force release, keymap)
>> and I think it works better than dding more and more DMI quirks into
>> kernel itself.
>
> It's limited to Dell hardware, so I think keeping a static list in the
> Dell laptop driver is reasonable. All we need is a list of hardware, and
> I'd really hope that Dell know which BIOS versions contain this code!
>
> --
> Matthew Garrett | mjg59@srcf.ucam.org
>
All Dell laptops are /supposed/ to adhere to the specification in
question. Unfortunately, not all machines are tested with Linux
during their development and on the OS they ship with that
functionality isn't always used in that specific way for rfkill.
--
Mario Limonciello
superm1@gmail.com
^ permalink raw reply
* Re: XFS Filename Hash and metadump
From: Alex Elder @ 2010-10-07 21:41 UTC (permalink / raw)
To: Michael Monnerie; +Cc: xfs
In-Reply-To: <201010052328.34390@zmi.at>
On Tue, 2010-10-05 at 23:28 +0200, Michael Monnerie wrote:
> On Dienstag, 5. Oktober 2010 Alex Elder wrote:
> > PS Two more observations:
> > - There is really no need for the characters to be truly random.
> > Making the generated name unique and different from the
> > original is sufficient. So (with the exception of the last
> > five bytes) we can select the characters however we like.
> > They could be a sequential series of names, for example,
> > rather than computing a random value for each.
>
> I was thinking the same when reading your description. Why not simply
> "number" the file names from 1 to whatever count of files/dirs there is
> within that dir?
>
I'm not entirely sure how best to implement it, and I'm open to
suggestions.
As a starting point, I will make it so the random characters making
up the first part of the name are printable, and could probably restrict
it even more than that (say, using lower-case alphabetic and numeric
characters).
A scheme with incrementing file names would need to accomodate names of
arbitrary length, too, and it might be better to make the varying part
be at the front of such names.
We need to be aware that there could be duplicates (filenames hashing
to the same value), even though that's unlikely.
In any case the last four and a half bytes of the name will need to
be in the full 8-bit range to make the hash work out right.
I have a few ideas for all of the above. They didn't get out in my
first draft of the patch series because like I said I wanted to get
early feedback rather than waiting to get other stuff implemented.
-Alex
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH] net: clear heap allocations for privileged ethtool actions
From: Kees Cook @ 2010-10-07 21:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, David S. Miller, Ben Hutchings, Jeff Garzik,
Jeff Kirsher, Peter P Waskiewicz Jr, netdev
In-Reply-To: <1286487085.3745.99.camel@edumazet-laptop>
Hi Eric,
On Thu, Oct 07, 2010 at 11:31:25PM +0200, Eric Dumazet wrote:
> Le jeudi 07 octobre 2010 à 14:10 -0700, Kees Cook a écrit :
> > Several other ethtool functions leave heap uncleared (potentially) by
> > drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
> > are well controlled. In some situations (e.g. unchecked error conditions),
> > the heap will remain unchanged in areas before copying back to userspace.
> > Note that these are less of an issue since these all require CAP_NET_ADMIN.
>
> > @@ -775,7 +775,7 @@ static int ethtool_get_regs(struct net_device *dev, char __user *useraddr)
> > if (regs.len > reglen)
> > regs.len = reglen;
> >
> > - regbuf = kmalloc(reglen, GFP_USER);
> > + regbuf = kzalloc(reglen, GFP_USER);
> > if (!regbuf)
> > return -ENOMEM;
> >
> > --
> > 1.7.1
> >
>
> Are you sure this is not hiding a more problematic problem ?
>
> Code does :
>
> reglen = ops->get_regs_len(dev);
> if (regs.len > reglen)
> regs.len = reglen;
> regbuf = kmalloc(reglen, GFP_USER);
>
> So we can not copy back kernel memory.
>
> However, what happens if user provides regs.len = 1 byte, and driver
> get_regs() doesnt properly checks regs.len and write past end of regbuf
> -> We probably write on other parts of kernel memory
This code is basically a max() call from what I see.
regbuf = kmalloc(max(regs.len, ops->get_regs_len(dev)), GFP_USER);
If the user passes regs.len = 1, it will be ignored in favor of reglen,
so we'll not write past the end of regbuf, unless I'm misunderstanding.
-Kees
--
Kees Cook
Ubuntu Security Team
^ permalink raw reply
* Re: [PATCH 2/2] keys: added cleanup code for trusted and encrypted key types
From: James Morris @ 2010-10-07 21:38 UTC (permalink / raw)
To: Mimi Zohar
Cc: Roberto Sassu, keyrings, linux-crypto, David Howells,
David Safford, Rajiv Andrade, linux-security-module
In-Reply-To: <1286485501.2809.9.camel@localhost.localdomain>
On Thu, 7 Oct 2010, Mimi Zohar wrote:
> Thanks for catching this! This patch applies cleanly to the
> trusted/encrypted patch set posted today.
>
> thanks,
>
> Acked-by: Mimi Zohar <zohar@us.ibm.com>
It's probably best if you incorporate these fixes into your patches, so we
don't commit known-broken code into the tree.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* mmotm 2010-10-07-14-08 uploaded
From: akpm @ 2010-10-07 21:08 UTC (permalink / raw)
To: mm-commits, linux-kernel
The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
and will soon be available at
git://zen-kernel.org/kernel/mmotm.git
It contains the following patches against 2.6.36-rc7:
mm-alloc_large_system_hash-printk-overflow-on-16tb-boot.patch
memcg-fix-thresholds-with-use_hierarchy-==-1.patch
maintainers-haavard-has-moved.patch
maintainers-add-samsung-s5p-series-fimc-maintainers.patch
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
linux-next.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
arch-arm-plat-omap-iovmmc-fix-end-address-of-vm-area-comparation-in-alloc_iovm_area.patch
audit-call-tty_audit_push_task-outside-preempt-disabled.patch
audit-do-not-send-uninitialized-data-for-audit_tty_get.patch
audit-use-rcu-for-task-lookup-protection.patch
backlight-fix-88pm860x_bl-macro-collision.patch
cciss-fix-botched-tag-masking-for-scsi-tape-commands.patch
arch-mips-include-asm-fcntlh-needs-typesh.patch
time-compensate-for-rounding-on-odd-frequency-clocksources.patch
x86-enable-arch_dma_addr_t_64bit-with-x86_64-highmem64g.patch
arch-x86-kernel-entry_64s-fix-build-with-gas-2161.patch
arch-x86-kernel-entry_32s-i386-too.patch
drivers-char-agp-parisc-agpc-eliminate-memory-leak.patch
audit-add-support-to-match-lsm-labels-on-user-audit-messages.patch
fs-btrfs-use-memdup_user.patch
fs-btrfs-use-err_cast.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
gcc-46-btrfs-clean-up-unused-variables-nonbugs.patch
btrfs-only-bug_on-when-the-errno-is-not-enoent.patch
fs-btrfs-inodec-eliminate-memory-leak.patch
btrfs-dont-dereference-extent_mapping-if-null.patch
fsldma-move-dma_slave-support-functions-to-the-driver.patch
powerpc-enable-arch_dma_addr_t_64bit-with-arch_phys_addr_t_64bit.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
drivers-media-ir-ene_irc-fix-null-dereference.patch
drivers-media-video-cx23885-cx23885-corec-fix-cx23885_dev_checkrevision.patch
fs-notify-fanotify-fanotify_userc-fix-warnings.patch
fsnotify-remove-alignment-padding-from-fsnotify_mark-on-64-bit-builds.patch
drivers-i2c-busses-i2c-pasemic-fix-unsigned-return-type.patch
softirq-improve-preempt-count-error-message.patch
softirq-cleanup-preempt-check.patch
tile-enable-arch_dma_addr_t_64bit.patch
timer_list-remove-alignment-padding-on-64-bit-when-config_timer_stats.patch
timer-initialize-the-field-slack-of-timer_list.patch
kernel-time-use-array_size-macro-in-timecomparec.patch
timer-make-try_to_del_timer_sync-safe-on-both-hardirq-context-and-up.patch
timer-del_timer_sync-can-be-used-in-softirq-context.patch
timer-warn-when-del_timer_sync-used-in-hardirq-context.patch
timer-permit-statically-declared-work-with-deferrable-timers.patch
posix-timers-annotate-lock_timer.patch
readme-cite-nconfig.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
led-class-always-implement-blinking.patch
leds-driver-for-national-semiconductor-lp5521-chip.patch
leds-driver-for-national-semiconductors-lp5523-chip.patch
leds-update-lp552x-support-kconfig-and-makefile.patch
documentation-led-drivers-lp5521-and-lp5523.patch
mips-enable-arch_dma_addr_t_64bit-with-highmem-64bit_phys_addr-64bit.patch
mtdpart-memory-accessor-interface-for-mtd-layer.patch
jffs2-use-cond_resched-instead-of-yield.patch
net-avoid-limits-overflow.patch
drivers-video-backlight-s6e63m0c-set-permissions-on-gamma_table-file-to-0444.patch
backlight-fix-blanking-for-lms283gf05-lcd.patch
backlight-fix-blanking-for-l4f00242t03-lcd.patch
backlight-s6e63m0-unregister-backlight-device-and-remove-sysfs-attribute-file-in-s6e63m0_remove.patch
backlight-s6e63m0-fix-section-mismatch.patch
backlight-add-low-threshold-to-pwm-backlight.patch
drivers-power-ds2782_batteryc-fix-ds2782-battery-driver-units.patch
bluetooth-simplify-l2cap-streaming-mode-sending.patch
btusb-patch-add_apple_macbookpro62.patch
serial8250-ratelimit-too-much-work-error.patch
serial8250-ratelimit-too-much-work-error-fix.patch
serial8250-ratelimit-too-much-work-error-fix-fix.patch
md-check-return-code-of-read_sb_page.patch
s390-enable-arch_dma_addr_t_64bit-with-64bit.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
percpu-fix-list_head-init-bug-in-__percpu_counter_init.patch
drivers-message-fusion-mptsasc-fix-warning.patch
block-m68k-z2ram-correct-printing-of-sector_t.patch
lirc-make-struct-file_operations-pointer-const.patch
drivers-usb-gadget-amd5536udcc-fix-error-path.patch
vfs-introduce-fmode_neg_offset-for-allowing-negative-f_pos.patch
vfs-remove-a-warning-on-open_fmode.patch
vfs-add-__fmode_exec.patch
vfs-fix-infinite-loop-caused-by-clone_mnt-race.patch
vfs-ignore-error-on-forced-remount.patch
vfs-fix-per-mount-read-write.patch
vfs-add-sb_force_remount_readonly-helper.patch
vfs-allow-mnt_want_write-to-sleep.patch
vfs-allow-mnt_want_write-to-sleep-fix.patch
vfs-keep-list-of-mounts-for-each-superblock.patch
vfs-protect-remounting-superblock-read-only.patch
vfs-fs_may_remount_ro-turn-unnecessary-check-into-a-warn_on.patch
vfs-mark-mounts-read-only-on-forced-remount.patch
mm.patch
vmcore-it-is-not-experimental-any-more.patch
documentation-filesystems-proctxt-improve-smaps-field-documentation.patch
mm-smaps-export-mlock-information.patch
oom-add-per-mm-oom-disable-count.patch
oom-add-per-mm-oom-disable-count-protect-oom_disable_count-with-task_lock-in-fork.patch
oom-add-per-mm-oom-disable-count-use-old_mm-for-oom_disable_count-in-exec.patch
oom-avoid-killing-a-task-if-a-thread-sharing-its-mm-cannot-be-killed.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
writeback-remove-nonblocking-encountered_congestion-references.patch
include-linux-pageblock-flagsh-fix-set_pageblock_flags-macro-definiton.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled.patch
mm-only-build-per-node-scan_unevictable-functions-when-numa-is-enabled-cleanup.patch
mm-compaction-fix-compactpagefailed-counting.patch
memory-hotplug-fix-notifiers-return-value-check.patch
memory-hotplug-unify-is_removable-and-offline-detection-code.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
vmscan-prevent-background-aging-of-anon-page-in-no-swap-system.patch
mm-mempolicy-check-return-code-of-check_range.patch
mm-add-account_page_writeback.patch
writeback-add-nr_dirtied-and-nr_written-to-proc-vmstat.patch
writeback-add-nr_dirtied-and-nr_written-to-proc-vmstat-update.patch
writeback-add-sys-devices-system-node-node-vmstat.patch
writeback-add-sys-devices-system-node-node-vmstat-update.patch
writeback-report-dirty-thresholds-in-proc-vmstat.patch
mm-fix-typo-in-mmh-when-node_not_in_page_flags.patch
vmscan-delete-dead-code.patch
tracing-vmscan-add-trace-events-for-lru-list-shrinking.patch
writeback-account-for-time-spent-congestion_waited.patch
vmscan-synchronous-lumpy-reclaim-should-not-call-congestion_wait.patch
vmscan-narrow-the-scenarios-lumpy-reclaim-uses-synchrounous-reclaim.patch
vmscan-remove-dead-code-in-shrink_inactive_list.patch
vmscan-isolated_lru_pages-stop-neighbour-search-if-neighbour-cannot-be-isolated.patch
writeback-do-not-sleep-on-the-congestion-queue-if-there-are-no-congested-bdis.patch
writeback-do-not-sleep-on-the-congestion-queue-if-there-are-no-congested-bdis-or-if-significant-congestion-is-not-being-encountered-in-the-current-zone.patch
writeback-do-not-sleep-on-the-congestion-queue-if-there-are-no-congested-bdis-or-if-significant-congestion-is-not-being-encounted-in-the-current-zone-fix.patch
writeback-remove-the-internal-5%-low-bound-on-dirty_ratio.patch
vmscantmpfs-treat-used-once-pages-on-tmpfs-as-used-once.patch
mm-strictly-nested-kmap_atomic.patch
mm-stack-based-kmap_atomic.patch
mm-stack-based-kmap_atomic-checkpatch-fixes.patch
mm-stack-based-kmap_atomic-fix.patch
mm-remove-pte_map_nested.patch
perf-x86-fix-up-kmap_atomic-type.patch
mm-highmem-documentation.patch
mm-add-a-might_sleep_if-in-dma_pool_alloc.patch
mm-remove-alignment-padding-from-anon_vma-on-some-64-bit-builds.patch
mm-filemap_fault-unique-path-for-locking-page.patch
mm-retry-page-fault-when-blocking-on-disk-transfer.patch
x86-access_error-api-cleanup.patch
mm-remove-temporary-variable-on-generic_file_direct_write.patch
mm-add-casts-to-from-gfp_t-in-gfp_to_alloc_flags.patch
mm-wrap-get_locked_pte-using-__cond_lock.patch
mm-add-lock-release-annotation-on-do_wp_page.patch
mm-wrap-follow_pte-using-__cond_lock.patch
rmap-annotate-lock-context-change-on-page_lock_anon_vma.patch
rmap-wrap-page_check_address-using-__cond_lock.patch
rmap-make-anon_vma_free-static.patch
rmap-make-anon_vma_free-static-fix.patch
vmalloc-rename-temporary-variable-in-__insert_vmap_area.patch
vmalloc-annotate-lock-context-change-on-s_start-stop.patch
mm-declare-some-external-symbols.patch
vmstat-include-compactionh-when-config_compaction.patch
vmstat-include-compactionh-when-config_compaction-fix.patch
mm-fix-sparse-warnings-on-gfp_zone_table-bad.patch
memblock-fix-big-size-with-find_region.patch
define-madv_hugepage.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-unmap-unused-i-o-space.patch
hpet-fix-unwanted-interrupt-due-to-stale-irq-status-bit.patch
hpet-fix-style-problems.patch
documentation-timers-hpet_examplec-add-supporting-info-for-hpet_example.patch
hpet-factor-timer-allocate-from-open.patch
hpet-factor-timer-allocate-from-open-fix.patch
alpha-enable-arch_dma_addr_t_64bit.patch
m68k-__pa-cast-arg-to-long.patch
uml-define-config_no_dma.patch
uml-fix-config_static_link=y-build-failure-with-newer-glibc.patch
kernelh-add-minmax3-macros.patch
kernelh-add-minmax3-macros-fix.patch
replace-nested-max-min-macros-with-maxmin3-macro.patch
m68knommu-blackfin-remove-old-assembler-only-flags-bit-definitions.patch
include-linux-kernelh-add-__must_check-to-strict_strto.patch
add-the-common-dma_addr_t-typedef-to-include-linux-typesh.patch
modules-no-need-to-align-modinfo-strings.patch
use-clear_page-copy_page-in-favor-of-memset-memcpy-on-whole-pages.patch
fuse-use-clear_highpage-and-km_user0-instead-of-km_user1.patch
ihex-add-support-for-cs-ip-eip-records.patch
drivers-misc-phantomc-add-missing-warning-messages-in-phantom_probe.patch
fcntl-make-exported-headers-use-strict-posix-types.patch
init-mark-__user-address-space-on-string-literals.patch
kernel-userc-add-lock-release-annotation-on-free_user.patch
fs-allow-for-more-than-231-files.patch
stop_machine-convert-cpu-notifier-to-return-encapsulate-errno-value.patch
kernel-remove-pf_flusher.patch
misc-devices-do-not-enable-by-default.patch
printk-fixup-declaration-of-kmsg_reasons.patch
printk-add-lock-context-annotation.patch
printk-change-type-of-boot_delay-to-int.patch
printk-declare-printk_ratelimit_state-in-ratelimith.patch
printk-declare-printk_ratelimit_state-in-ratelimith-fix.patch
vsprintfc-use-default-pointer-field-size-for-null-strings.patch
vsprintfc-use-default-pointer-field-size-for-null-strings-fix.patch
lib-fix-scnprintf-if-size-is-==-0.patch
scripts-get_maintainerpl-add-git-blame-rolestats-authored-lines-information.patch
scripts-get_maintainerpl-use-correct-indentation.patch
scripts-get_maintainerpl-dont-search-maintainers-for-keywords-or-emails.patch
scripts-get_maintainerpl-add-default-git-fallback-remove-default-git.patch
scripts-get_maintainerpl-use-get_maintainerconf-from-then-home-then-scripts.patch
scripts-get_maintainerpl-add-interactive-mode.patch
scripts-get_maintainerpl-improve-interactive-ui.patch
scripts-get_maintainerpl-update-interactive-ui-improve-hg-runtime.patch
scripts-get_maintainerpl-use-case-insensitive-name-de-duplication.patch
scripts-get_maintainerpl-fix-mailmap-handling.patch
scripts-get_maintainerpl-correct-indentation-in-a-few-places.patch
scripts-get_maintainerpl-use-mailmap-in-name-deduplication-and-other-updates.patch
scripts-get_maintainerpl-dont-deduplicate-unnamed-addresses-ie-mailing-lists.patch
maintainers-fix-colibri-pxa270-file-pattern.patch
maintainers-merge-imote2-and-stargate.patch
maintainers-merge-s3c-244x-sections.patch
maintainers-merge-s3c6400-and-6410-to-64xx.patch
maintainers-remove-usb-ov511-driver.patch
maintainers-remove-usb-zc0301-driver.patch
maintainers-use-t-git-and-whitespace-trivia.patch
lib-bitmapc-use-hex_to_bin.patch
idr-fix-idr_pre_get-locking-description.patch
idr-fix-idr_pre_get-locking-description-fix.patch
lib-div64c-document-that-div64_u64-is-not-precise-on-32bit-platforms.patch
percpu_counter-add-debugobj-support.patch
lib-kconfigdebug-add-list_sort-debugging-switch.patch
lib-list_sort-test-use-more-reasonable-printk-levels.patch
lib-list_sort-test-use-generic-random32.patch
lib-list_sort-test-improve-errors-handling.patch
lib-list_sort-test-unify-test-messages.patch
lib-list_sort-test-check-element-addresses.patch
bitops-make-asm-generic-bitops-findh-more-generic.patch
bitops-remove-duplicated-extern-declarations.patch
drivers-mmc-host-omapc-use-resource_size.patch
drivers-mmc-host-omap_hsmmcc-use-resource_size.patch
checkpatch-fix-regressions-in-fix-handling-of-leading-spaces.patch
checkpatch-types-may-sit-on-a-line-on-their-own.patch
checkpatch-suggest-cleanpatch-and-cleanfile-when-appropriate.patch
checkpatch-ensure-we-do-not-collapse-bracketed-sections-into-constants.patch
checkpatch-handle-casts-better-fixing-false-categorisation-of-as-binary.patch
checkpatch-returning-errno-typically-should-be-negative.patch
checkpatch-add-check-for-space-after-struct-union-and-enum.patch
checkpatch-simplify-and-consolidate-missing-space-after-checks.patch
checkpatch-ensure-kconfig-help-checks-only-apply-when-we-are-adding-help.patch
checkpatch-check-for-incorrect-permissions.patch
checkpatch-add-additional-attribute-defines.patch
checkpatch-update-copyright-dates.patch
checkpatch-clean-up-structure-definition-macro-handline.patch
checkpatch-handle-export_symbol-for-device_attr-and-similar.patch
checkpatch-statement-block-context-analyser-should-look-at-sanitised-lines.patch
checkpatch-version-031.patch
scripts-checkpatchpl-add-warnings-for-static-char-that-could-be-static-const-char.patch
select-rename-estimate_accuracy-to-select_estimate_accuracy.patch
epoll-make-epoll_wait-use-the-hrtimer-range-feature.patch
dmi-log-board-system-and-bios-information-v2.patch
drivers-char-vt_ioctlc-fix-vt_openqry-error-value.patch
vcs-add-poll-fasync-support-fix-fix.patch
rtc-rtc-lpc32xx-introduce-rtc-driver-for-the-lpc32xx-soc-v4.patch
rtc-bfin-shrink-optimize-interrupt-handler-a-bit.patch
rtc-bfin-add-debug-markers-to-suspend-resume-paths.patch
drivers-rtc-classc-fix-device_register-error-handling.patch
rtc-omap-let-device-wakeup-capability-be-configured-from-chip-init-logic.patch
gpio-add-driver-for-basic-memory-mapped-gpio-controllers.patch
gpio-add-driver-for-basic-memory-mapped-gpio-controllers-fix.patch
gpiolib-fix-have_gpio_lib-leftovers-in-asm-generic-gpioh.patch
drivers-video-atafbc-remove-undead-ifdef-atafb_falcon.patch
drivers-video-matrox-matroxfb_dac1064c-remove-undead-ifdef-config_fb_matrox_g.patch
savagefb-fix-ddc-for-savage-4.patch
drivers-video-matrox-matroxfb_mavenc-fix-unsigned-return-type.patch
fbmem-ix-whitespace.patch
cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch
fbmem-fix-fb_read-fb_write-unaligned-accesses.patch
drivers-video-gbefbc-eliminate-memory-leak.patch
jbd-remove-dependency-on-__gfp_nofail.patch
isofs-work-around-for-rock-ridgejoliet-cds-with-empty-iso-root-directory.patch
isofs-fix-isofs_get_blocks-for-8tb-files.patch
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
doc-clarify-the-behaviour-of-dirty_ratio-dirty_bytes.patch
cgroup_freezer-unnecessary-test-in-cgroup_freezing_or_frozen.patch
cgroup_freezer-fix-can_attach-to-prohibit-moving-from-to-freezing-frozen-cgroups.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions.patch
cgroup_freezer-update_freezer_state-does-incorrect-state-transitions-checkpatch-fixes.patch
cgroup-add-clone_children-control-file.patch
cgroup-make-the-mount-options-parsing-more-accurate.patch
cgroups-add-check-for-strcpy-destination-string-overflow.patch
cgroup-notify-ns_cgroup-deprecated.patch
memcg-fix-race-in-file_mapped-accouting-flag-management.patch
memcg-avoid-lock-in-updating-file_mapped-was-fix-race-in-file_mapped-accouting-flag-management.patch
memcg-use-for_each_mem_cgroup.patch
memcg-cpu-hotplug-aware-percpu-count-updates.patch
memcg-cpu-hotplug-aware-percpu-count-updates-fix.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
memcg-generic-filestat-update-interface.patch
ptrace-annotate-lock-context-change-on-exit_ptrace.patch
ptrace-change-signature-of-sys_ptrace-and-friends.patch
ptrace-cleanup-ptrace_request.patch
ptrace-change-signature-of-arch_ptrace.patch
ptrace-cleanup-arch_ptrace-on-x86.patch
ptrace-cleanup-arch_ptrace-on-arm.patch
ptrace-cleanup-arch_ptrace-on-avr32.patch
ptrace-cleanup-arch_ptrace-and-friends-on-blackfin.patch
ptrace-cleanup-arch_ptrace-on-cris.patch
ptrace-cleanup-arch_ptrace-on-frv.patch
ptrace-cleanup-arch_ptrace-on-h8300.patch
ptrace-cleanup-arch_ptrace-on-m32r.patch
ptrace-cleanup-arch_ptrace-on-m68k.patch
ptrace-cleanup-arch_ptrace-on-m68knommu.patch
ptrace-cleanup-arch_ptrace-on-microblaze.patch
ptrace-cleanup-arch_ptrace-on-mips.patch
ptrace-cleanup-arch_ptrace-on-mn10300.patch
ptrace-cleanup-arch_ptrace-on-parisc.patch
ptrace-cleanup-arch_ptrace-on-powerpc.patch
ptrace-cleanup-arch_ptrace-on-score.patch
ptrace-cleanup-arch_ptrace-on-sh.patch
ptrace-cleanup-arch_ptrace-on-sparc.patch
ptrace-cleanup-arch_ptrace-on-tile.patch
ptrace-cleanup-arch_ptrace-on-um.patch
ptrace-cleanup-arch_ptrace-on-xtensa.patch
signals-annotate-lock_task_sighand.patch
signals-annotate-lock-context-change-on-ptrace_stop.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2.patch
core_pattern-fix-long-parameters-was-truncated-by-core_pattern-handler-update-2-checkpatch-fixes.patch
default-config_core_dump_default_elf_headers=y.patch
exit-add-lock-context-annotation-on-find_new_reaper.patch
proc-pid-smaps-export-amount-of-anonymous-memory-in-a-mapping.patch
proc-pid-smaps-export-amount-of-anonymous-memory-in-a-mapping-doc.patch
proc-pid-pagemap-document-in-documentation-filesystems-proctxt.patch
procfs-fix-proc-softirqs-formatting.patch
ipc-shmc-add-rss-and-swap-size-information-to-proc-sysvipc-shm.patch
ipc-shmc-add-rss-and-swap-size-information-to-proc-sysvipc-shm-v2.patch
ipmi-fix-__init-and-__exit-attribute-locations.patch
rocket-release_region-or-error-path.patch
drivers-char-hvc_consolec-remove-unneeded-__set_current_statetask_running.patch
hvc_console-fix-dropping-of-characters-when-output-byte-channel-is-full.patch
rapidio-fix-rapidio-sysfs-hierarchy.patch
rapidio-powerpc-85xx-modify-rio-port-write-interrupt-handler.patch
rapidio-use-stored-ingress-port-number-instead-of-register-read.patch
rapidio-add-relation-links-between-rio-device-structures.patch
rapidio-add-default-handler-for-error-stopped-state.patch
rapidio-modify-sysfs-initialization-for-switches.patch
rapidio-add-handling-of-orphan-port-write-message.patch
rapidio-add-device-access-check-into-the-enumeration.patch
rapidio-add-support-for-idt-cps-gen2-switches.patch
rapidio-add-handling-of-redundant-routes.patch
rapidio-fix-idle2-bits-corruption.patch
fs-execc-provide-the-correct-process-pid-to-the-pipe-helper.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
delayacct-align-to-8-byte-boundary-on-64-bit-systems.patch
taskstats-separate-taskstats-commands.patch
taskstats-split-fill_pid-function.patch
fuse-use-release_pages.patch
affs-testing-the-wrong-variable.patch
pps-trivial-fixes.patch
pps-declare-variables-where-they-are-used-in-switch.patch
pps-fix-race-in-pps_fetch-handler.patch
pps-unify-timestamp-gathering.patch
pps-access-pps-device-by-direct-pointer.patch
pps-convert-printk-pr_-to-dev_.patch
pps-move-idr-stuff-to-ppsc.patch
pps-add-async-pps-event-handler.patch
pps-add-async-pps-event-handler-fix.patch
pps-dont-disable-interrupts-when-using-spin-locks.patch
pps-use-bug_on-for-kernel-api-safety-checks.patch
pps-simplify-conditions-a-bit.patch
ntp-add-hardpps-implementation.patch
pps-capture-monotonic_raw-timestamps-as-well.patch
pps-add-kernel-consumer-support.patch
pps-add-parallel-port-pps-client.patch
pps-add-parallel-port-pps-signal-generator.patch
memstick-a-few-changes-to-core.patch
memstick-add-support-for-legacy-memorysticks.patch
memstick-add-driver-for-ricoh-r5c592-card-reader.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-fix.patch
memstick-core-fix-device_register-error-handling.patch
w1-dont-allow-arbitrary-users-to-remove-w1-devices.patch
aio-bump-i_count-instead-of-using-igrab.patch
kernel-resourcec-handle-reinsertion-of-an-already-inserted-resource.patch
ramoops-use-the-platform-data-structure-instead-of-module-params.patch
ramoops-use-the-platform-data-structure-instead-of-module-params-fix.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
mutex-subsystem-synchro-test-module-add-missing-header-file.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
getblk-handle-2tb-devices.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* Re: [PATCH] net: clear heap allocations for privileged ethtool actions
From: Ben Hutchings @ 2010-10-07 21:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Kees Cook, linux-kernel, David S. Miller, Jeff Garzik,
Jeff Kirsher, Peter P Waskiewicz Jr, netdev
In-Reply-To: <1286487085.3745.99.camel@edumazet-laptop>
On Thu, 2010-10-07 at 23:31 +0200, Eric Dumazet wrote:
> Le jeudi 07 octobre 2010 à 14:10 -0700, Kees Cook a écrit :
> > Several other ethtool functions leave heap uncleared (potentially) by
> > drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
> > are well controlled. In some situations (e.g. unchecked error conditions),
> > the heap will remain unchanged in areas before copying back to userspace.
> > Note that these are less of an issue since these all require CAP_NET_ADMIN.
>
> > @@ -775,7 +775,7 @@ static int ethtool_get_regs(struct net_device *dev, char __user *useraddr)
> > if (regs.len > reglen)
> > regs.len = reglen;
> >
> > - regbuf = kmalloc(reglen, GFP_USER);
> > + regbuf = kzalloc(reglen, GFP_USER);
Actually, I recently changed this to vmalloc() so your patch won't
apply.
> > if (!regbuf)
> > return -ENOMEM;
> >
> > --
> > 1.7.1
> >
>
> Are you sure this is not hiding a more problematic problem ?
>
> Code does :
>
> reglen = ops->get_regs_len(dev);
> if (regs.len > reglen)
> regs.len = reglen;
> regbuf = kmalloc(reglen, GFP_USER);
>
> So we can not copy back kernel memory.
>
> However, what happens if user provides regs.len = 1 byte, and driver
> get_regs() doesnt properly checks regs.len and write past end of regbuf
> -> We probably write on other parts of kernel memory
[...]
Why should the driver's get_regs() check regs.len? The buffer is
allocated based on reglen which is provided by the driver, not the user.
reglen (length of the kernel buffer) is not reduced; regs.len (length of
the user buffer) is. That lets the user know how much of the user
buffer was actually used.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [U-Boot] [PATCH V5 0/2] ARMV7: Add support for the Versatile Express Quad Cortex A9 platform
From: matt.waddel at linaro.org @ 2010-10-07 21:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1280373167-20890-2-git-send-email-matt.waddel@linaro.org>
From: Matt Waddel <matt.waddel@linaro.org>
Matt Waddel (2):
Adds support for the ARM quad-core Cortex-A9 processor.
This system includes a motherboard(Versatile Express), daughterboard
(Coretile), and SOC(Cortex-A9 quad core). The serial port, ethernet,
and flash systems work with these additions. The naming convention
is:
SOC -> CortexA9 quad core = ca9x4
daughterboard -> Coretile = ct
motherboard -> Versatile Express = vxp
This gives ca9x4_ct_vxp.c as the board support file.
The 2nd patch fixes a bug in the "set baudrate xxx" functionality and
fixes some of the code problems like CamelCase and IO accessors.
---
Version 2 -
Removed unneeded multi-core low_level setup code.
Version 3 -
Patch 1)
1) Fixups from Wolfgang's code review:
- Remove CamelCase variable definitions, keep lists sorted, tab indents
only, remove trailing empty lines, remove unneeded configuration options,
use I/O accessors, added while(1) loop in reset command
2) Simplified board_init declarations
3) Added CONFIG_INITRD_TAG declaration
4) Removed unneeded assembly directives from Makefile
Patch 2)
1) Replaced IO_WRITE and IO_READ calls in serial_pl01x.c with calls to
readl() and writel(). Fixed commenting and CamelCase problems.
Version 4 -
1) Refactored to work with the "next" branch
2) Fixed a bug in the 2nd flash bank definition
Version 5 -
1) Refactored to apply to the tip of git tree.
2) Improved the environment settings and added the run command option
MAINTAINERS | 4 +
MAKEALL | 1 +
arch/arm/include/asm/arch-armv7/sysctrl.h | 70 +++++++++
arch/arm/include/asm/arch-armv7/systimer.h | 50 +++++++
arch/arm/include/asm/arch-armv7/wdt.h | 55 +++++++
board/armltd/vexpress/Makefile | 49 ++++++
board/armltd/vexpress/ca9x4_ct_vxp.c | 220 ++++++++++++++++++++++++++++
board/armltd/vexpress/config.mk | 23 +++
board/armltd/vexpress/u-boot.lds | 65 ++++++++
boards.cfg | 1 +
drivers/serial/serial_pl01x.c | 93 +++++-------
include/configs/ca9x4_ct_vxp.h | 196 +++++++++++++++++++++++++
12 files changed, 772 insertions(+), 55 deletions(-)
create mode 100644 arch/arm/include/asm/arch-armv7/sysctrl.h
create mode 100644 arch/arm/include/asm/arch-armv7/systimer.h
create mode 100644 arch/arm/include/asm/arch-armv7/wdt.h
create mode 100644 board/armltd/vexpress/Makefile
create mode 100644 board/armltd/vexpress/ca9x4_ct_vxp.c
create mode 100644 board/armltd/vexpress/config.mk
create mode 100644 board/armltd/vexpress/u-boot.lds
create mode 100644 include/configs/ca9x4_ct_vxp.h
^ permalink raw reply
* [Bug 16140] Suspend To RAM/ Resume broken - Radeon KMS on RV250
From: bugzilla-daemon @ 2010-10-07 21:38 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-16140-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=16140
--- Comment #20 from Sedat Dilek <sedat.dilek@gmail.com> 2010-10-07 21:38:46 ---
You can't read?
It was done with xz-utils from official Debian/sid.
Shall I attach in another archive-format?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Matthew Garrett @ 2010-10-07 21:37 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mario Limonciello, Keng-Yu Lin, len.brown, alan-jenkins,
platform-driver-x86, linux-kernel
In-Reply-To: <20101007213027.GA18628@core.coreip.homeip.net>
On Thu, Oct 07, 2010 at 02:30:28PM -0700, Dmitry Torokhov wrote:
> We have this strategy for bunch of input stuff (force release, keymap)
> and I think it works better than dding more and more DMI quirks into
> kernel itself.
It's limited to Dell hardware, so I think keeping a static list in the
Dell laptop driver is reasonable. All we need is a list of hardware, and
I'd really hope that Dell know which BIOS versions contain this code!
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Newbie Question About Dev-Interface Method
From: Rory Filer @ 2010-10-07 21:37 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1286480883-25589-1-git-send-email-rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Hi
I'm working on a proof-of-concept device which contains several chips connected to the same adapter (/dev/ic2-0) on the I2C bus. Some of these have kernel-space drivers (e.g. GPIO Expander) and some don't. For the ones that don't I've opted to use the method described in the kernel Documentation/i2c/dev-interface document. This works great and does all I need for now. This is the general procedure I'm following as outlined in kernel - Documentation/i2c/dev-interface.
- open /dev/i2c-N
- Set the chip's address by calling ioctl(file, I2C_SLAVE, address)
- interact with the chip using read/write or smb calls, etc.
- close the file when done
I'm assuming that a kernel space chip driver like our gpio expander (pca953x.c) also uses the same adapter driver as my user-space application since that expander chip is on the same bus. My question is, what happens if a kernel driver is using the bus at the same time my user-mode application is? Even if the user space app. may not be running when the chip driver runs, the adapter has an address written into it via the ioctl() call, I noted above. Can unpredictable results occur in this scenario? I think I could protect against it by writing a thread to serialize accesses to the I2C bus, but that only works if my entire application is running inside one process. I'm hoping someone on the list might be able to advise.
Regards,
Rory
^ permalink raw reply
* Re: [PATCH 2/3] Revert "Eliminated global exerrno."
From: Jonathan Nieder @ 2010-10-07 21:34 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Blake, Gerrit Pape, dash, Krzysztof A. Sobiecki, Jari Aalto
In-Reply-To: <20101007043715.GA15658@gondor.apana.org.au>
Herbert Xu wrote:
> sh -c 'trap "exec nosuchfile" EXIT; exit 3'; echo $?
>
> This makes dash exit with 127 instead of 3 as it does now.
>
> AFAIK the wording of POSIX is such that we should return 3, however,
> it does seem that every other shell exits with 127.
On 'exec':
"If exec is specified with command, it shall replace the shell with
command without creating a new process." (1)
"If command is specified, exec shall not return to the shell; rather,
the exit status of the process shall be the exit status of the program
implementing command, which overlaid the shell. If command is not
found, the exit status shall be 127. If command is found, but it is
not an executable utility, the exit status shall be 126. If a
redirection error occurs (see Consequences of Shell Errors ), the
shell shall exit with a value in the range 1-125. Otherwise, exec
shall return a zero exit status." (2)
On 'exit':
"...
A trap on EXIT shall be executed before the shell terminates, except
when the exit utility is invoked in that trap itself, in which case
the shell shall exit immediately." (3)
"The exit status [of the exit utility -jrn] shall be n, if specified.
Otherwise, the value shall be the exit value of the last command
executed, or zero if no command was executed. When exit is executed in
a trap action, the last command is considered to be the command that
executed immediately preceding the trap action." (4)
The passage (3) seems to mean that "exit" triggers an EXIT trap
(except, to avoid having to deal with recursion, when the "exit"
occurs within an EXIT trap). Then the exec builtin is invoked,
resulting (according to (2)) in an exit(127) without returning to the
shell.
So I think the proposed behavior fits the spec.
Regards,
Jonathan
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Luis R. Rodriguez @ 2010-10-07 21:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ben Greear, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimxp703Gy_Atg8=wpFszRDR=OJCXwOUKRh-a-d7@mail.gmail.com>
On Thu, Oct 7, 2010 at 2:31 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 12:27 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Thu, 2010-10-07 at 12:22 -0700, Ben Greear wrote:
>>
>>> After reboot, and re-run of the script,
>>> I saw this in the logs, and shortly after,
>>> the SLUB poison warning dumped to screen.
>>>
>>> Maybe those DMA errors are serious?
>>
>>> ath: Failed to stop TX DMA in 100 msec after killing last frame
>>> ath: Failed to stop TX DMA. Resetting hardware!
>>
>> That's TX DMA, it can hardly result in invalid memory writes like the
>> ones you've been seeing.
>>
>> I'm still convinced something is wrong with ath9k RX DMA, as you've seen
>> the contents of frames written to already freed memory regions. Since I
>> don't know anything about ath9k, you should probably not rely on me
>> though :-)
>
> I'm on this now. Lets play.
>
> I had to remove /lib/udev/rules.d/75-persistent-net-generator.rules
> to avoid Ubuntu trying to remember the device names and it creating
> stax_rename names.
> I just ran your script with some modifications. You can find it here:
>
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/scripts/poo.pl
>
> I then ran:
>
> for i in $(seq 0 31) ; do sudo dhclient seq$i; done
>
> It took about 10 minutes to get IP addresses for all interfaces but it
> got there eventually. Odd enough I was unable to ping the AP from any
> interface though. Not sure what that was about. But I got no oops, no
> slub dump. All I got was some more delba warnings which seems to
> indicate we haven't caught all the cases for its use:
>
> [ 3622.660344] addBA response timer expired on tid 0
> [ 3622.660373] Tx BA session stop requested for 68:7f:74:3b:b1:0f tid 0
> [ 3622.680133] addBA response timer expired on tid 0
> [ 3622.687196] Tx BA session stop requested for 68:7f:74:3b:b1:0f tid 0
> [ 3623.110077] addBA response timer expired on tid 0
> [ 3623.110123] Tx BA session stop requested for 68:7f:74:3b:b1:0f tid 0
> [ 3628.935895] sta10: authenticate with 68:7f:74:3b:b1:10 (try 1)
> [ 3628.937194] switched off addBA timer for tid 0
> [ 3628.937196] Aggregation is on for tid 0
> [ 3628.937239] Stopping Tx BA session for 68:7f:74:3b:b1:0f tid 0
> [ 3628.937243] ------------[ cut here ]------------
> [ 3628.937263] WARNING: at include/net/mac80211.h:2694
> rate_control_send_low+0xd3/0x140 [mac80211]()
> [ 3628.937265] Hardware name: 6460DWU
> [ 3628.937266] Modules linked in: binfmt_misc ppdev
> snd_hda_codec_analog rfcomm sco bridge joydev stp bnep l2cap nouveau
> ath9k snd_hda_intel mac80211 snd_hda_codec snd_hwdep snd_pcm ttm btusb
> ath9k_common thinkpad_acpi ath9k_hw bluetooth drm_kms_helper
> snd_seq_midi snd_rawmidi pcmcia snd_seq_midi_event drm snd_seq ath
> snd_timer snd_seq_device tpm_tis i2c_algo_bit cfg80211 snd nvram tpm
> tpm_bios yenta_socket pcmcia_rsrc video psmouse output pcmcia_core
> serio_raw soundcore snd_page_alloc intel_agp lp parport ohci1394
> e1000e ieee1394 ahci libahci
> [ 3628.937307] Pid: 49, comm: kworker/u:3 Tainted: G W
> 2.6.36-rc6-wl+ #263
> [ 3628.937310] Call Trace:
> [ 3628.937317] [<ffffffff8105ffcf>] warn_slowpath_common+0x7f/0xc0
> [ 3628.937320] [<ffffffff8106002a>] warn_slowpath_null+0x1a/0x20
> [ 3628.937329] [<ffffffffa032f603>] rate_control_send_low+0xd3/0x140 [mac80211]
> [ 3628.937336] [<ffffffffa038bfd8>] ath_get_rate+0x48/0x570 [ath9k]
> [ 3628.937340] [<ffffffff812b9f39>] ? put_dec+0x59/0x60
> [ 3628.937349] [<ffffffffa032f42e>] rate_control_get_rate+0x8e/0x190 [mac80211]
> [ 3628.937360] [<ffffffffa0339928>]
> ieee80211_tx_h_rate_ctrl+0x1a8/0x4e0 [mac80211]
> [ 3628.937370] [<ffffffffa033a000>] invoke_tx_handlers+0x100/0x140 [mac80211]
> [ 3628.937379] [<ffffffffa033a0c5>] ieee80211_tx+0x85/0x240 [mac80211]
> [ 3628.937384] [<ffffffff8147b890>] ? skb_release_data+0xd0/0xe0
> [ 3628.937386] [<ffffffff8147d72f>] ? pskb_expand_head+0x10f/0x1a0
> [ 3628.937397] [<ffffffffa033a336>] ieee80211_xmit+0xb6/0x1d0 [mac80211]
> [ 3628.937399] [<ffffffff8147b9d3>] ? __alloc_skb+0x83/0x170
> [ 3628.937409] [<ffffffffa033a4a4>] ieee80211_tx_skb+0x54/0x70 [mac80211]
> [ 3628.937418] [<ffffffffa03230ad>] ieee80211_send_delba+0x11d/0x190 [mac80211]
> [ 3628.937427] [<ffffffffa0323a18>]
> ieee80211_stop_tx_ba_cb+0x1b8/0x240 [mac80211]
> [ 3628.937431] [<ffffffff81036c89>] ? default_spin_lock_flags+0x9/0x10
> [ 3628.937440] [<ffffffffa032e031>] ieee80211_iface_work+0x271/0x340 [mac80211]
> [ 3628.937450] [<ffffffffa032ddc0>] ? ieee80211_iface_work+0x0/0x340 [mac80211]
> [ 3628.937453] [<ffffffff8107a203>] process_one_work+0x123/0x440
> [ 3628.937457] [<ffffffff8107c750>] worker_thread+0x170/0x400
> [ 3628.937460] [<ffffffff8107c5e0>] ? worker_thread+0x0/0x400
> [ 3628.937463] [<ffffffff81080b76>] kthread+0x96/0xa0
> [ 3628.937466] [<ffffffff8100bea4>] kernel_thread_helper+0x4/0x10
> [ 3628.937469] [<ffffffff81080ae0>] ? kthread+0x0/0xa0
> [ 3628.937472] [<ffffffff8100bea0>] ? kernel_thread_helper+0x0/0x10
> [ 3628.937474] ---[ end trace 9dd0d025ccb9b75c ]---
> [ 3628.937980] switched off addBA timer for tid 0
> [ 3628.937982] Aggregation is on for tid 0
>
> But other than this I got nothing. I left the box sit there for about
> 1 hour and came back and it was still going with no issues. Mind you,
> I can't ping but that seems like another issue.
>
> You can find my logs here:
>
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/logs/2010/10-07-stress-sta-01/
Doh, I did not have CONFIG_SLUB_DEBUG_ON=y so building now with that.
Luis
^ permalink raw reply
* Re: "do_IRQ: 0.89 No irq handler for vector (irq -1)"
From: Thomas Gleixner @ 2010-10-07 21:35 UTC (permalink / raw)
To: Dave Airlie; +Cc: LKML, Ingo Molnar, Jesse Barnes
In-Reply-To: <alpine.LFD.2.00.1010072227420.2484@localhost6.localdomain6>
On Thu, 7 Oct 2010, Thomas Gleixner wrote:
> On Thu, 7 Oct 2010, Dave Airlie wrote:
> Oct 7 22:24:19 ionos kernel: Console: switching to colour VGA+ 80x25
> Oct 7 22:24:22 ionos kernel: drm: unregistered panic notifier
> Oct 7 22:24:22 ionos kernel: vga_switcheroo: disabled
> Oct 7 22:24:22 ionos kernel: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/git/linux-2.6/arch/x86/mm/fault.c:1074
> Oct 7 22:24:22 ionos kernel: in_atomic(): 0, irqs_disabled(): 1, pid: 2681, name: udevd
> Oct 7 22:24:22 ionos kernel: Pid: 2681, comm: udevd Not tainted 2.6.36-rc7 #4
> Oct 7 22:24:22 ionos kernel: Call Trace:
> Oct 7 22:24:22 ionos kernel: [<ffffffff8103d3d1>] __might_sleep+0xed/0xef
> Oct 7 22:24:22 ionos kernel: [<ffffffff81452d81>] do_page_fault+0x1b2/0x2bb
> Oct 7 22:24:22 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
> Oct 7 22:24:22 ionos kernel: [<ffffffff8106af14>] ? lock_hrtimer_base+0x22/0x50
> Oct 7 22:24:22 ionos kernel: [<ffffffff8106af5e>] hrtimer_get_remaining+0x1c/0x46
> Oct 7 22:24:22 ionos kernel: [<ffffffff8105119d>] itimer_get_remtime+0x16/0x3c
>
> That means that the hrtimer in the shared signal handler is corrupted. Uurg.
>
> Oct 7 22:24:22 ionos kernel: [<ffffffff8106d127>] ? abort_creds+0x1a/0x1c
> Oct 7 22:24:22 ionos kernel: [<ffffffff81051445>] do_setitimer+0x97/0x1e7
> Oct 7 22:24:22 ionos kernel: [<ffffffff81051674>] alarm_setitimer+0x3a/0x60
> Oct 7 22:24:22 ionos kernel: [<ffffffff8105a248>] sys_alarm+0xe/0x12
> Oct 7 22:24:22 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
> Oct 7 22:24:22 ionos kernel: BUG: unable to handle kernel paging request at 00000000934a2400
>
> Something is fishy here. That's not a kernel address
I tried the patch you pointed me to on IRC:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=dab8dcfa3c8e3b021a138bee7c17791b4991ba55
The first test worked fine. But after I added some debugging I got
another weird corruption this time on the first unload:
Oct 7 23:21:24 ionos kernel: Console: switching to colour VGA+ 80x25
Oct 7 23:21:31 ionos kernel: drm: unregistered panic notifier
Oct 7 23:21:31 ionos kernel: vga_switcheroo: disabled
Oct 7 23:21:31 ionos kernel: [drm:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
That one scares me :)
Oct 7 23:21:31 ionos kernel: [drm] Module unloaded
Oct 7 23:21:32 ionos kernel: BUG: sleeping function called from invalid context at /home/tglx/work/kernel/git/linux-2.6/arch/x86/mm/fault.c:1074
Oct 7 23:21:32 ionos kernel: in_atomic(): 0, irqs_disabled(): 1, pid: 1243, name: dbus-daemon
Oct 7 23:21:32 ionos kernel: Pid: 1243, comm: dbus-daemon Not tainted 2.6.36-rc7+ #6
Oct 7 23:21:32 ionos kernel: Call Trace:
Oct 7 23:21:32 ionos kernel: [<ffffffff8103d3d1>] __might_sleep+0xed/0xef
Oct 7 23:21:32 ionos kernel: [<ffffffff81452d81>] do_page_fault+0x1b2/0x2bb
Oct 7 23:21:32 ionos kernel: [<ffffffff8144ff55>] page_fault+0x25/0x30
Oct 7 23:21:32 ionos kernel: [<ffffffff813988bd>] ? sock_alloc_send_pskb+0xd6/0x2eb
Oct 7 23:21:32 ionos kernel: [<ffffffff8110044d>] ? __kmalloc_node_track_caller+0x149/0x154
Oct 7 23:21:32 ionos kernel: [<ffffffff813988bd>] ? sock_alloc_send_pskb+0xd6/0x2eb
Oct 7 23:21:32 ionos kernel: [<ffffffff8139cc02>] __alloc_skb+0x83/0x141
Oct 7 23:21:32 ionos kernel: [<ffffffff813988bd>] sock_alloc_send_pskb+0xd6/0x2eb
Oct 7 23:21:32 ionos kernel: [<ffffffff81039551>] ? __wake_up_common+0x4e/0x84
Oct 7 23:21:32 ionos kernel: [<ffffffff81399130>] ? cred_to_ucred+0x6d/0x79
Oct 7 23:21:32 ionos kernel: [<ffffffff81398ae7>] sock_alloc_send_skb+0x15/0x17
Oct 7 23:21:32 ionos kernel: [<ffffffff81425818>] unix_stream_sendmsg+0x11c/0x2c3
Oct 7 23:21:32 ionos kernel: [<ffffffff81394921>] __sock_sendmsg+0x6b/0x77
Oct 7 23:21:32 ionos kernel: [<ffffffff81396cc3>] ? sock_aio_write+0x0/0xd4
Oct 7 23:21:32 ionos kernel: [<ffffffff81396d83>] sock_aio_write+0xc0/0xd4
Oct 7 23:21:32 ionos kernel: [<ffffffff8110be39>] do_sync_readv_writev+0xc1/0x100
Oct 7 23:21:32 ionos kernel: [<ffffffff8110bba3>] ? might_fault+0x21/0x23
Oct 7 23:21:32 ionos kernel: [<ffffffff8110bbd4>] ? copy_from_user+0x2f/0x31
Oct 7 23:21:32 ionos kernel: [<ffffffff811d0379>] ? security_file_permission+0x2e/0x33
Oct 7 23:21:32 ionos kernel: [<ffffffff8110cb2e>] do_readv_writev+0xa7/0x129
Oct 7 23:21:32 ionos kernel: [<ffffffff8111bcfc>] ? d_kill+0x3e/0x46
Oct 7 23:21:32 ionos kernel: [<ffffffff8110d7f6>] ? fput+0x214/0x223
Oct 7 23:21:32 ionos kernel: [<ffffffff8110cbf3>] vfs_writev+0x43/0x4e
Oct 7 23:21:32 ionos kernel: [<ffffffff8110cce3>] sys_writev+0x4a/0x93
Oct 7 23:21:32 ionos kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Oct 7 23:21:32 ionos kernel: BUG: unable to handle kernel paging request at 00000037362e313a
We are again dereferencing a user space address.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] net: clear heap allocations for privileged ethtool actions
From: Ben Hutchings @ 2010-10-07 21:34 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, David S. Miller, Jeff Garzik, Jeff Kirsher,
Peter P Waskiewicz Jr, netdev
In-Reply-To: <20101007211004.GA20267@outflux.net>
On Thu, 2010-10-07 at 14:10 -0700, Kees Cook wrote:
> Several other ethtool functions leave heap uncleared (potentially) by
> drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
> are well controlled. In some situations (e.g. unchecked error conditions),
> the heap will remain unchanged in areas before copying back to userspace.
> Note that these are less of an issue since these all require CAP_NET_ADMIN.
>
> Cc: stable@kernel.org
> Signed-off-by: Kees Cook <kees.cook@canonical.com>
> ---
> net/core/ethtool.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 7a85367..fb9cf30 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -397,7 +397,7 @@ static noinline_for_stack int ethtool_get_rxfh_indir(struct net_device *dev,
> (KMALLOC_MAX_SIZE - sizeof(*indir)) / sizeof(*indir->ring_index))
> return -ENOMEM;
> full_size = sizeof(*indir) + sizeof(*indir->ring_index) * table_size;
> - indir = kmalloc(full_size, GFP_USER);
> + indir = kzalloc(full_size, GFP_USER);
> if (!indir)
> return -ENOMEM;
>
[...]
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
You could alternately recalculate full_size before copying back to the
user buffer:
full_size = sizeof(*indir) + sizeof(*indir->ring_index) * indir->size;
but kzalloc() is more obviously safe.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: clear heap allocations for privileged ethtool actions
From: Eric Dumazet @ 2010-10-07 21:31 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, David S. Miller, Ben Hutchings, Jeff Garzik,
Jeff Kirsher, Peter P Waskiewicz Jr, netdev
In-Reply-To: <20101007211004.GA20267@outflux.net>
Le jeudi 07 octobre 2010 à 14:10 -0700, Kees Cook a écrit :
> Several other ethtool functions leave heap uncleared (potentially) by
> drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
> are well controlled. In some situations (e.g. unchecked error conditions),
> the heap will remain unchanged in areas before copying back to userspace.
> Note that these are less of an issue since these all require CAP_NET_ADMIN.
> @@ -775,7 +775,7 @@ static int ethtool_get_regs(struct net_device *dev, char __user *useraddr)
> if (regs.len > reglen)
> regs.len = reglen;
>
> - regbuf = kmalloc(reglen, GFP_USER);
> + regbuf = kzalloc(reglen, GFP_USER);
> if (!regbuf)
> return -ENOMEM;
>
> --
> 1.7.1
>
Are you sure this is not hiding a more problematic problem ?
Code does :
reglen = ops->get_regs_len(dev);
if (regs.len > reglen)
regs.len = reglen;
regbuf = kmalloc(reglen, GFP_USER);
So we can not copy back kernel memory.
However, what happens if user provides regs.len = 1 byte, and driver
get_regs() doesnt properly checks regs.len and write past end of regbuf
-> We probably write on other parts of kernel memory
An audit is needed, but first driver I checked is buggy
(drivers/net/qlcnic/qlcnic_ethtool.c)
->
memset(p, 0, qlcnic_get_regs_len(dev));
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.