Re: scsi: delete decade+ obsolete aic7xxx_old driver
On 09/17/2013 08:27 PM, Paul Bolle wrote: > On Mon, 2013-09-16 at 21:51 -0400, Paul Gortmaker wrote: >> Currently we have people wasting time building it during routine testing, >> and then wasting more time re-researching the known reported warnings, >> only to find that nobody really is willing to integrate the fixes[3] for >> it. >> >> [...] >> >> [3] https://lkml.org/lkml/2012/10/29/215 > > Well, this didn't end up as an entire waste of my time. After that > message I sent a patch to Fedora's kernel list, and a reminder a few > months later[1]. That prompted Josh Boyer to remove this old driver from > the Fedora build[2]. > > And now that driver is disabled in all kernels that Fedora currently > ships. I'm not familiar with any complaints about this decision. > Ok, good to know. So this patch appears to be good, then. Acked-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
On Tue, Sep 17, 2013 at 07:53:36PM +, KY Srinivasan wrote: > > > Thanks Gleb. Here is the link for the latest Hyper-V specification: > > > http://www.microsoft.com/en-us/download/details.aspx?id=39289 > > > > > > This spec talks about how migration is handled with regards to TSC. > > > > > All I can see is "15.4.3 Partition Reference TSC Mechanism". I see > > nothing about HV_X64_MSR_TSC_FREQUENCY specifically. To access this MSR > > a partition needs AccessFrequencyMsrs privilege, may be partition that > > cab be migrated does not have this privilege? > > If you use the MSR to read the TSC frequency, then indeed when you migrate > then there > is no guarantee that the TSC frequency won't change when you migrate. The > approach > described in section 15.4.3 is the preferred approach that can accommodate > migration. > Thanks. -- Gleb. -- 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 5/5] lib: Add error string support to printks
On Tue, 2013-09-17 at 18:08 -0500, danielfsan...@att.net wrote: > This adds an extension for the integral format specifier suffix of 'e', > so that the format %[duxXo]e will result in printing an number (as > before) in addition to a name and descrption for an error code, if such > support is enabled and a name and descrption is found. > > My initial thought was to use the glibc extension of '%m', but this > format specifier uses the value of libc's errno and adding a value > breaks gcc's printf parsing. I'm not convinced that the 'e' extension > is optimal, although there are only four instances of this pattern in > the kernel that would need to be changed. > > git grep -E '".*%[#0\ +\-]*[0-9]*[hljzt]*[idoxXu]e' > > Alternatively, 'E' was another thought for a suffix as well. I'd much rather see another %p extension used instead of generating odd output given normal printf formats. %pE might work -- 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] modules: add support for soft module dependencies
On Tue, Sep 17, 2013 at 11:10 PM, Rusty Russell wrote: > Lucas De Marchi writes: >> On Thu, Sep 12, 2013 at 9:07 PM, Rusty Russell wrote: >>> Lucas De Marchi writes: On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu wrote: > On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote: >> Herbert Xu writes: >> > Hi Rusty: >> > >> > I don't know why this patch never went into the kernel, even >> > though the corresponding features have been added to modprobe >> > in most if not all distros. >> >> Because Andreas never sent me the patch? This is the first I've *heard* >> of this feature. Looks like it didn't hit lkml either. And what was >> 2/2? > > 2/2 was the patch to actually use this in crc32c. > >> It's not how I would have done this: post-deps are more flexibly done at >> runtime, because the module may have to do work to figure out what to >> pull in. But since it already exists, I'll apply this patch: it doesn't >> cost the kernel anything. But it did cause boot failures. The file modules.softdep file was supposed to be informational until now. That's why depmod put a comment saying to "copy on user's discretion to /etc/modules.d" instead of parsing it directly. >>> >>> I'm happy to change this macro to create a modinfo line like >>> "softdep:" >> >> how is that solving the issue that this macro can be used to designate >> a mandatory or optional dependency >> (https://lkml.org/lkml/2013/9/10/371)? If we decide the dependency is >> mandatory we can very well let modprobe use that dependency during >> module load > > I'm very close to sending Linus a revert commit at this point, since > there's no consensus on what it's for. > > *Clearly* softdep shouldn't indicate a mandatory dependency. We already > have a way (several) to make mandatory dependencies! > > And the "pre:" vs "post:" thing is just weird. If a module wants a post > dependency, you can request_module() it from a workqueue. > >>> ie. tools like mkinitrd could pick it up and try to find a matching >>> module, but depmod would ignore it. >> >> Some mkinitrd-like use whatever depmod/modprobe tells them it's >> needed. So kmod still needs to know about it. > > It sounds like we should create a separate tool, which takes a list of > modules and spits out the full pathname of all dependencies. *That* > tool should include soft dependencies. > >>> It's really up to Lucas, since this affects him. >> >> IMO saying "this is an optional dependency and we can work without" >> doesn't buy us much. Distros will end up putting the soft dep in >> /etc/modules.d, kmod will always use them anyway and failing to load >> the soft dep will fail the module load. I'd like to have no distro >> files in /etc/modules.d in future. > > I assumed modprobe would handle soft dependencies in modules and try to > pull them in, but *not* fail if they don't work. Iff the module doesn't *exist*. If it failed to load or failed for any other reason then we will abort trying to load the other module. However this is one thing we can change in modprobe to make it consistent and more predictable. But we really need to reach a consensus. > > The previous way of doing this was: > install foo modprobe foo_softdep 2>/dev/null; modprobe > --ignore-install foo $CMDLINE_OPTS I just hope this is in no way an incentive for people using install commands ;-) Lucas De Marchi -- 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] x86: Useless inode var and Coding style fixes
On Tue, 2013-09-17 at 23:54 -0300, Geyslan G. Bem wrote:
> Coding style and printk strings fixes.
[]
> diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
[]
> @@ -299,12 +301,12 @@ static int load_aout_binary(struct linux_binprm * bprm)
>
> if ((fd_offset & ~PAGE_MASK) != 0 && printk_ratelimit())
> {
> - printk(KERN_WARNING
> + printk(KERN_WARNING
> "fd_offset is not page aligned. Please convert
> program: %s\n",
> bprm->file->f_path.dentry->d_name.name);
[]
> @@ -388,12 +388,12 @@ static int load_aout_library(struct file *file)
> if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
> if (printk_ratelimit())
> {
> - printk(KERN_WARNING
> + printk(KERN_WARNING
> "N_TXTOFF is not page aligned. Please convert
> library: %s\n",
> file->f_path.dentry->d_name.name);
I'd rather see these printks were fixed like this:
---
fs/binfmt_aout.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index 89dec7f..3c9ec06 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -292,17 +293,12 @@ static int load_aout_binary(struct linux_binprm * bprm)
}
} else {
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
- (N_MAGIC(ex) != NMAGIC) && printk_ratelimit())
- {
- printk(KERN_NOTICE "executable not page aligned\n");
- }
+ (N_MAGIC(ex) != NMAGIC))
+ pr_notice_ratelimited("executable not page aligned\n");
- if ((fd_offset & ~PAGE_MASK) != 0 && printk_ratelimit())
- {
- printk(KERN_WARNING
- "fd_offset is not page aligned. Please convert
program: %s\n",
- bprm->file->f_path.dentry->d_name.name);
- }
+ if ((fd_offset & ~PAGE_MASK) != 0)
+ pr_warn_ratelimited("fd_offset is not page aligned.
Please convert program: %s\n",
+
bprm->file->f_path.dentry->d_name.name);
if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
@@ -386,12 +382,8 @@ static int load_aout_library(struct file *file)
start_addr = ex.a_entry & 0xf000;
if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
- if (printk_ratelimit())
- {
- printk(KERN_WARNING
- "N_TXTOFF is not page aligned. Please convert
library: %s\n",
- file->f_path.dentry->d_name.name);
- }
+ pr_warn_ratelimited("N_TXTOFF is not page aligned. Please
convert library: %s\n",
+ file->f_path.dentry->d_name.name);
vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
read_code(file, start_addr, N_TXTOFF(ex),
--
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/8][v4] powerpc/perf: Rename Power8 macros to start with PME
On 09/14/2013 06:19 AM, Sukadev Bhattiprolu wrote:
> We use helpers like GENERIC_EVENT_ATTR() to list the generic events in
> sysfs. To avoid name collisions, GENERIC_EVENT_ATTR() requires the perf
> event macros to start with PME.
We got all the raw event codes covered for P7 with the help of
power7-events-list.h
enumeration.
/*
* Power7 event codes.
*/
#define EVENT(_name, _code) \
PME_##_name = _code,
enum {
#include "power7-events-list.h"
};
#undef EVENT
Just wondering if its a good idea to name change these selected macros to be
consumed
by GENERIC_EVENT_ATTR() right here for this purpose or we need to get the
comprehensive
list of raw events for P8 first. Just an idea.
Regards
Anshuman
--
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-next: Tree for Sep 18
Hi all, Changes since 20130917: Removed trees: davinci, 4xx, hwpoison, ptr-ret (all finished with) The vfs tree gained a conflict against the aio-direct tree. The drm-intel tree gained conflicts against Linus' tree. The gpio tree gained a build failure so I used the version from next-20130917. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 218 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (de0bc3d Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (272b98c Linux 3.12-rc1) Merging arm-current/fixes (272b98c Linux 3.12-rc1) Merging m68k-current/for-linus (21e884b m68k/m68knommu: Implement __get_user_unaligned/__put_user_unaligned()) Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2) Merging powerpc-merge/merge (363edbe powerpc: Default arch idle could cede processor on pseries) Merging sparc/master (4de9ad9 Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging net/master (269aa75 tcp: fix RTO calculated from cached RTT) Merging ipsec/master (73a695f cxgb4: remove workqueue when driver registration fails) Merging sound-current/for-linus (3d0049e Merge tag 'asoc-v3.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (a923874 Merge tag 'pci-v3.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging wireless/master (f4e1a4d rt2800: change initialization sequence to fix system freeze) Merging driver-core.current/driver-core-linus (272b98c Linux 3.12-rc1) Merging tty.current/tty-linus (93a8d41 n_tty: Fix EOF push index when termios changes) Merging usb.current/usb-linus (42f4891 Merge tag 'fixes-for-v3.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging staging.current/staging-linus (c3cb718 staging: line6: add bounds check in snd_toneport_source_put()) Merging char-misc.current/char-misc-linus (272b98c Linux 3.12-rc1) Merging input-current/for-linus (c7dc657 Input: evdev - add EVIOCREVOKE ioctl) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c1 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-linus (d24
[PATCH] Staging: bcm: PHSModule.c: Matching the function definition with function declaration
From: Shalin Mehta
The function implementations of the PHSModule didn't match with the
declaration. The functions are static
in the declaration but in the implemntation they are non-static
Signed-off-by: Shalin Mehta
---
NOTE: Submitting the same patch again. Added NOTE at wrong location the
previous submission
drivers/staging/bcm/PHSModule.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/bcm/PHSModule.c b/drivers/staging/bcm/PHSModule.c
index af5d22f..56c5bee 100644
--- a/drivers/staging/bcm/PHSModule.c
+++ b/drivers/staging/bcm/PHSModule.c
@@ -596,7 +596,7 @@ ULONG PhsDeleteSFRules(IN void *pvContext, IN B_UINT16
uiVcid)
* 0 if successful,
* >0 Error.
*/
-ULONG PhsCompress(IN void *pvContext,
+static ULONG PhsCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN void *pvInputBuffer,
@@ -677,7 +677,7 @@ ULONG PhsCompress(IN void *pvContext,
* 0 if successful,
* >0 Error.
*/
-ULONG PhsDeCompress(IN void *pvContext,
+static ULONG PhsDeCompress(IN void *pvContext,
IN B_UINT16 uiVcid,
IN void *pvInputBuffer,
OUT void *pvOutputBuffer,
@@ -829,7 +829,7 @@ UINT GetServiceFlowEntry(IN struct bcm_phs_table
*psServiceFlowTable,
return PHS_INVALID_TABLE_INDEX;
}
-UINT GetClassifierEntry(IN struct bcm_phs_classifier_table *pstClassifierTable,
+static UINT GetClassifierEntry(IN struct bcm_phs_classifier_table
*pstClassifierTable,
IN B_UINT32 uiClsid, enum bcm_phs_classifier_context
eClsContext,
OUT struct bcm_phs_classifier_entry
**ppstClassifierEntry)
{
@@ -880,7 +880,7 @@ static UINT GetPhsRuleEntry(IN struct
bcm_phs_classifier_table *pstClassifierTab
return PHS_INVALID_TABLE_INDEX;
}
-UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16 uiClsId,
+static UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN B_UINT16
uiClsId,
IN struct bcm_phs_table *psServiceFlowTable,
struct bcm_phs_rule *psPhsRule,
B_UINT8 u8AssociatedPHSI)
@@ -913,7 +913,7 @@ UINT CreateSFToClassifierRuleMapping(IN B_UINT16 uiVcid, IN
B_UINT16 uiClsId,
return uiStatus;
}
-UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
+static UINT CreateClassiferToPHSRuleMapping(IN B_UINT16 uiVcid,
IN B_UINT16 uiClsId,
IN struct bcm_phs_entry *pstServiceFlowEntry,
struct bcm_phs_rule *psPhsRule,
@@ -1239,7 +1239,7 @@ void DumpPhsRules(struct bcm_phs_extension
*pDeviceExtension)
* header.
* 0 -If PHS rule is NULL.If PHSI is 0 indicateing packet as
uncompressed.
*/
-int phs_decompress(unsigned char *in_buf,
+static int phs_decompress(unsigned char *in_buf,
unsigned char *out_buf,
struct bcm_phs_rule *decomp_phs_rules,
UINT *header_size)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] cpufreq: use correct values of cpus in __cpufreq_remove_dev_finish()
On 17 September 2013 21:48, Viresh Kumar wrote: > On 17 September 2013 20:50, Stephen Warren wrote: > Yes, I have asked Rafael to get this in for rc2 and few others too.. > Waiting for his reply though.. Its applied now by Rafael.. -- 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] iio: ti_am335x_adc: Add continuous sampling support
Hi Zubair, On Tue, Sep 17, 2013 at 09:44:07AM +0500, Zubair Lutfullah wrote: > + > + ret = devm_request_threaded_irq(indio_dev->dev.parent, > + irq, > + pollfunc_th, pollfunc_bh, > + flags, indio_dev->name, > + indio_dev); > + if (ret) > + goto error_kfifo_free; > + > + indio_dev->setup_ops = setup_ops; > + indio_dev->modes |= INDIO_BUFFER_HARDWARE; > + > + ret = iio_buffer_register(indio_dev, > + indio_dev->channels, > + indio_dev->num_channels); > + if (ret) > + goto error_free_irq; > + > + return 0; > + > +error_free_irq: > + devm_free_irq(indio_dev->dev.parent, irq, indio_dev); What is the point of using devm_* here if you are doing explicit management of the resource anyway (you explicitly release it in all code paths)? Thanks. -- Dmitry -- 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] modules: add support for soft module dependencies
Lucas De Marchi writes: > On Thu, Sep 12, 2013 at 9:07 PM, Rusty Russell wrote: >> Lucas De Marchi writes: >>> On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu >>> wrote: On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote: > Herbert Xu writes: > > Hi Rusty: > > > > I don't know why this patch never went into the kernel, even > > though the corresponding features have been added to modprobe > > in most if not all distros. > > Because Andreas never sent me the patch? This is the first I've *heard* > of this feature. Looks like it didn't hit lkml either. And what was > 2/2? 2/2 was the patch to actually use this in crc32c. > It's not how I would have done this: post-deps are more flexibly done at > runtime, because the module may have to do work to figure out what to > pull in. But since it already exists, I'll apply this patch: it doesn't > cost the kernel anything. >>> >>> But it did cause boot failures. The file modules.softdep file was >>> supposed to be informational until now. That's why depmod put a >>> comment saying to "copy on user's discretion to /etc/modules.d" >>> instead of parsing it directly. >> >> I'm happy to change this macro to create a modinfo line like >> "softdep:" > > how is that solving the issue that this macro can be used to designate > a mandatory or optional dependency > (https://lkml.org/lkml/2013/9/10/371)? If we decide the dependency is > mandatory we can very well let modprobe use that dependency during > module load I'm very close to sending Linus a revert commit at this point, since there's no consensus on what it's for. *Clearly* softdep shouldn't indicate a mandatory dependency. We already have a way (several) to make mandatory dependencies! And the "pre:" vs "post:" thing is just weird. If a module wants a post dependency, you can request_module() it from a workqueue. >> ie. tools like mkinitrd could pick it up and try to find a matching >> module, but depmod would ignore it. > > Some mkinitrd-like use whatever depmod/modprobe tells them it's > needed. So kmod still needs to know about it. It sounds like we should create a separate tool, which takes a list of modules and spits out the full pathname of all dependencies. *That* tool should include soft dependencies. >> It's really up to Lucas, since this affects him. > > IMO saying "this is an optional dependency and we can work without" > doesn't buy us much. Distros will end up putting the soft dep in > /etc/modules.d, kmod will always use them anyway and failing to load > the soft dep will fail the module load. I'd like to have no distro > files in /etc/modules.d in future. I assumed modprobe would handle soft dependencies in modules and try to pull them in, but *not* fail if they don't work. The previous way of doing this was: install foo modprobe foo_softdep 2>/dev/null; modprobe --ignore-install foo $CMDLINE_OPTS I agree this logic belongs in the kernel, we just have to figure out exactly how. 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/
[PATCH] [TRIVIAL] treewide: fix "usefull" typo
Signed-off-by: Michael Opdenacker
---
drivers/base/dma-contiguous.c| 2 +-
drivers/net/wireless/ath/ath5k/dma.c | 2 +-
sound/soc/codecs/alc5632.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 99802d6f..165c2c2 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -49,7 +49,7 @@ struct cma *dma_contiguous_default_area;
/*
* Default global CMA area size can be defined in kernel's .config.
- * This is usefull mainly for distro maintainers to create a kernel
+ * This is useful mainly for distro maintainers to create a kernel
* that works correctly for most supported systems.
* The size can be set in bytes or as a percentage of the total memory
* in the system.
diff --git a/drivers/net/wireless/ath/ath5k/dma.c
b/drivers/net/wireless/ath/ath5k/dma.c
index ce86f15..ba200b2 100644
--- a/drivers/net/wireless/ath/ath5k/dma.c
+++ b/drivers/net/wireless/ath/ath5k/dma.c
@@ -661,7 +661,7 @@ ath5k_hw_get_isr(struct ath5k_hw *ah, enum ath5k_int
*interrupt_mask)
ah->ah_txq_isr_txok_all |= AR5K_REG_MS(sisr1,
AR5K_SISR1_QCU_TXEOL);
- /* Currently this is not much usefull since we treat
+ /* Currently this is not much useful since we treat
* all queues the same way if we get a TXURN (update
* tx trigger level) but we might need it later on*/
if (pisr & AR5K_ISR_TXURN)
diff --git a/sound/soc/codecs/alc5632.c b/sound/soc/codecs/alc5632.c
index f2e62e4..19e9f22 100644
--- a/sound/soc/codecs/alc5632.c
+++ b/sound/soc/codecs/alc5632.c
@@ -614,7 +614,7 @@ struct _pll_div {
};
/* Note : pll code from original alc5632 driver. Not sure of how good it is */
-/* usefull only for master mode */
+/* useful only for master mode */
static const struct _pll_div codec_master_pll_div[] = {
{ 2048000, 8192000, 0x0ea0},
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [TRIVIAL] treewide: fix "distingush" typo
Signed-off-by: Michael Opdenacker --- arch/m32r/include/asm/mmu_context.h| 2 +- arch/mn10300/include/asm/mmu_context.h | 2 +- arch/powerpc/platforms/pseries/nvram.c | 2 +- arch/sh/include/asm/mmu_context.h | 2 +- arch/x86/kernel/cpu/amd.c | 2 +- drivers/input/serio/i8042.c| 2 +- drivers/md/raid5.h | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/m32r/include/asm/mmu_context.h b/arch/m32r/include/asm/mmu_context.h index a979a41..9fc78fc 100644 --- a/arch/m32r/include/asm/mmu_context.h +++ b/arch/m32r/include/asm/mmu_context.h @@ -45,7 +45,7 @@ static inline void get_new_mmu_context(struct mm_struct *mm) Flush all TLB and start new cycle. */ local_flush_tlb_all(); /* Fix version if needed. - Note that we avoid version #0 to distingush NO_CONTEXT. */ + Note that we avoid version #0 to distinguish NO_CONTEXT. */ if (!mc) mmu_context_cache = mc = MMU_CONTEXT_FIRST_VERSION; } diff --git a/arch/mn10300/include/asm/mmu_context.h b/arch/mn10300/include/asm/mmu_context.h index c67c2b5..75dbe69 100644 --- a/arch/mn10300/include/asm/mmu_context.h +++ b/arch/mn10300/include/asm/mmu_context.h @@ -71,7 +71,7 @@ static inline unsigned long allocate_mmu_context(struct mm_struct *mm) local_flush_tlb_all(); /* fix the TLB version if needed (we avoid version #0 so as to -* distingush MMU_NO_CONTEXT) */ +* distinguish MMU_NO_CONTEXT) */ if (!mc) *pmc = mc = MMU_CONTEXT_FIRST_VERSION; } diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c index d276cd3..10630ea 100644 --- a/arch/powerpc/platforms/pseries/nvram.c +++ b/arch/powerpc/platforms/pseries/nvram.c @@ -31,7 +31,7 @@ #define NVRW_CNT 0x20 /* - * Set oops header version to distingush between old and new format header. + * Set oops header version to distinguish between old and new format header. * lnx,oops-log partition max size is 4000, header version > 4000 will * help in identifying new header. */ diff --git a/arch/sh/include/asm/mmu_context.h b/arch/sh/include/asm/mmu_context.h index 21c5088..b9d9489 100644 --- a/arch/sh/include/asm/mmu_context.h +++ b/arch/sh/include/asm/mmu_context.h @@ -81,7 +81,7 @@ static inline void get_mmu_context(struct mm_struct *mm, unsigned int cpu) /* * Fix version; Note that we avoid version #0 -* to distingush NO_CONTEXT. +* to distinguish NO_CONTEXT. */ if (!asid) asid = MMU_CONTEXT_FIRST_VERSION; diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 903a264..3538a1b 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -339,7 +339,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c) #endif /* - * On a AMD dual core setup the lower bits of the APIC id distingush the cores. + * On a AMD dual core setup the lower bits of the APIC id distinguish the cores. * Assumes number of cores is a power of two. */ static void amd_detect_cmp(struct cpuinfo_x86 *c) diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c index 78e4de4..957e387 100644 --- a/drivers/input/serio/i8042.c +++ b/drivers/input/serio/i8042.c @@ -1031,7 +1031,7 @@ static void i8042_controller_reset(bool force_reset) /* * i8042_panic_blink() will turn the keyboard LEDs on or off and is called * when kernel panics. Flashing LEDs is useful for users running X who may - * not see the console and will help distingushing panics from "real" + * not see the console and will help distinguishing panics from "real" * lockups. * * Note that DELAY has a limit of 10ms so we will not get stuck here diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h index 2113ffa..b42e6b4 100644 --- a/drivers/md/raid5.h +++ b/drivers/md/raid5.h @@ -49,7 +49,7 @@ * can't distinguish between a clean block that has been generated * from parity calculations, and a clean block that has been * successfully written to the spare ( or to parity when resyncing). - * To distingush these states we have a stripe bit STRIPE_INSYNC that + * To distinguish these states we have a stripe bit STRIPE_INSYNC that * is set whenever a write is scheduled to the spare, or to the parity * disc if there is no spare. A sync request clears this bit, and * when we find it set with no buffers locked, we know the sync is -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] S+core Architecture : fix bugs for compiling and support necessary functions
On Wed, Sep 18, 2013 at 11:42:54AM +0800, Lennox Wu wrote: > Hi Guenter, > What does the "e-mail is not signed" mean? I try to search some > information, but I still do not understand what you say. > This is a signed e-mail. It guarantees that it is from me and not from an arbitrary person calling himself Guenter Roeck. Guenter > Best, > Lennox > > 2013/9/16 Lennox Wu : > > OK, thanks for your reminding, most the format is referenced from > > other git pull requests, however, I still miss something, I will fix > > them. > > > > How detailed content shold a summary have? I indeed have made some > > summary in the commits. Could you give me an example? > > > > About why I didn't send a copy to Linus. Because the document > > SubmittingPatches has no this rule. I indeed notice that many git > > pull requests sent a copy to Linus, but I think I should follow the > > documented rule. If it is a new rule, thanks for telling me the rule > > ,and maybe the document should be added this rule. > > Adopt this rule... > > " > > 5) Select e-mail destination. > > Look through the MAINTAINERS file and the source code, and determine > > if your change applies to a specific subsystem of the kernel, with > > an assigned maintainer. If so, e-mail that person. The script > > scripts/get_maintainer.pl can be very useful at this step. > > If no maintainer is listed, or the maintainer does not respond, send > > your patch to the primary Linux kernel developer's mailing list, > > linux-kernel@vger.kernel.org. Most kernel developers monitor this > > e-mail list, and can comment on your changes. > > > > Do not send more than 15 patches at once to the vger mailing lists!!! > > > > Linus Torvalds is the final arbiter of all changes accepted into the > > Linux kernel. His e-mail address is . > > He gets a lot of e-mail, so typically you should do your best to -avoid- > > sending him e-mail. > > " > > > > Anyway, I appreciate your notifiction and I will fix this errors. > > > > Best, > > Lennox > > > > > > 2013/9/16 Guenter Roeck : > >> On Sat, Sep 14, 2013 at 05:42:07PM +0800, Lennox Wu wrote: > >>> Hi Linus, > >>> Please pull these updates for S+core architecture. These updates include > >>> updating information of maintainers, fix some trivial errors, and add > >>> a necessary function for supporting ipv6. > >>> > >>> The following changes since commit > >>> bdbdfdef5766c2a60185e946df242f1bc0d37c09 > >>> > >>> Merge tag 'hwmon-for-linus' of > >>> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging > >>> (Fri Sep 13 10:58:41 2013 -0700) > >>> > >>> on > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > >>> > >>> > >>> For you to fetch changes up to 969f99168b9dff2f6cc07cdf14255178d4397c4f > >>> > >>> g...@github.com:sctscore/official-linux.git tags/branch-linus-20130914 > >>> > >>> Best, > >>> Lennox Wu > >>> > >> Your e-mail is not signed. You don't even have a pgp key as far as > >> I can see, at least not one associated with your e-mail address. > >> How do you expect anyone to establish your identity ? > >> > >> In addition to that, the tag in your repository is not signed and > >> does not contain a summary of your changes. Your patches do not > >> have a Signed-off-by: tag. The pull message below appears to be > >> hand-edited and does not match an auto-generated pull request > >> (which should have given you a hint that the commit logs have > >> a problem). > >> > >> You did not even copy Linus on this e-mail. Do you really think > >> he would even notice your pull request, much less apply it ? > >> > >> Guenter > >> > >>> --- > >>> Summary these commits: > >>> 1. Fix some trivial errors for successfully compiling the latest > >>> version Linux kernel. > >>> 2. Provide necessary function for support IPV6. > >>> 3. Update the information of maintainers. > >>> > >>> Lennox Wu (8): > >>> score : Update the information of Score maintainers > >>> score : Implement the function csum_ipv6_magic > >>> score : arch/score/kernel/entry.S: fix wrong instructions > >>> score : arch/score/kernel/process.c : fix some typos > >>> score : Modify the MAKEFILE of Score > >>> > >>> MAINTAINERS |4 +- > >>> arch/score/Kconfig|4 ++ > >>> arch/score/Makefile |4 +- > >>> arch/score/include/asm/checksum.h | 93 > >>> - > >>> arch/score/include/asm/io.h |1 - > >>> arch/score/include/asm/pgalloc.h |2 +- > >>> arch/score/kernel/entry.S |4 +- > >>> arch/score/kernel/process.c |4 +- > >>> 8 files changed, 64 insertions(+), 52 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
[PATCH] doc: fix some typos in documentations
Fix some typos in five documentations, no functional change. Signed-off-by: Xishi Qiu --- Documentation/md.txt |2 +- Documentation/rfkill.txt |2 +- Documentation/rt-mutex-design.txt |2 +- Documentation/static-keys.txt |4 ++-- Documentation/sysfs-rules.txt |2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/md.txt b/Documentation/md.txt index fbb2fcb..f925666 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -533,7 +533,7 @@ also have found. The count in 'mismatch_cnt' is the number of sectors that were re-written, or (for 'check') would have been re-written. As most raid levels work in units of pages rather - than sectors, this my be larger than the number of actual errors + than sectors, this may be larger than the number of actual errors by a factor of the number of sectors in a page. bitmap_set_bits diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index 03c9d92..f430004 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt @@ -71,7 +71,7 @@ To create an rfkill driver, driver's Kconfig needs to have depends on RFKILL || !RFKILL to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL -case allows the driver to be built when rfkill is not configured, which which +case allows the driver to be built when rfkill is not configured, which case all rfkill API can still be used but will be provided by static inlines which compile to almost nothing. diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt index a5bcd7f..8666070 100644 --- a/Documentation/rt-mutex-design.txt +++ b/Documentation/rt-mutex-design.txt @@ -30,7 +30,7 @@ is something called unbounded priority inversion. That is when the high priority process is prevented from running by a lower priority process for an undetermined amount of time. -The classic example of unbounded priority inversion is were you have three +The classic example of unbounded priority inversion is where you have three processes, let's call them processes A, B, and C, where A is the highest priority process, C is the lowest, and B is in between. A tries to grab a lock that C owns and must wait and lets C run to release the lock. But in the diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt index 9f5263d..c4407a4 100644 --- a/Documentation/static-keys.txt +++ b/Documentation/static-keys.txt @@ -116,7 +116,7 @@ The branch(es) can then be switched via: static_key_slow_dec(); Thus, 'static_key_slow_inc()' means 'make the branch true', and -'static_key_slow_dec()' means 'make the the branch false' with appropriate +'static_key_slow_dec()' means 'make the branch false' with appropriate reference counting. For example, if the key is initialized true, a static_key_slow_dec(), will switch the branch to false. And a subsequent static_key_slow_inc(), will change the branch back to true. Likewise, if the @@ -236,7 +236,7 @@ label case adds: If we then include the padding bytes, the jump label code saves, 16 total bytes of instruction memory for this small function. In this case the non-jump label -function is 80 bytes long. Thus, we have have saved 20% of the instruction +function is 80 bytes long. Thus, we have saved 20% of the instruction footprint. We can in fact improve this even further, since the 5-byte no-op really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp. However, we have not yet implemented optimal no-op sizes (they are currently diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt index c1a1fd6..a5f985e 100644 --- a/Documentation/sysfs-rules.txt +++ b/Documentation/sysfs-rules.txt @@ -47,7 +47,7 @@ versions of the sysfs interface. at device creation and removal - the unique key to the device at that point in time - the kernel's path to the device directory without the leading -/sys, and always starting with with a slash +/sys, and always starting with a slash - all elements of a devpath must be real directories. Symlinks pointing to /sys/devices must always be resolved to their real target and the target path must be used to access the device. -- 1.7.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: [GIT PULL] S+core Architecture : fix bugs for compiling and support necessary functions
Hi Guenter, What does the "e-mail is not signed" mean? I try to search some information, but I still do not understand what you say. Best, Lennox 2013/9/16 Lennox Wu : > OK, thanks for your reminding, most the format is referenced from > other git pull requests, however, I still miss something, I will fix > them. > > How detailed content shold a summary have? I indeed have made some > summary in the commits. Could you give me an example? > > About why I didn't send a copy to Linus. Because the document > SubmittingPatches has no this rule. I indeed notice that many git > pull requests sent a copy to Linus, but I think I should follow the > documented rule. If it is a new rule, thanks for telling me the rule > ,and maybe the document should be added this rule. > Adopt this rule... > " > 5) Select e-mail destination. > Look through the MAINTAINERS file and the source code, and determine > if your change applies to a specific subsystem of the kernel, with > an assigned maintainer. If so, e-mail that person. The script > scripts/get_maintainer.pl can be very useful at this step. > If no maintainer is listed, or the maintainer does not respond, send > your patch to the primary Linux kernel developer's mailing list, > linux-kernel@vger.kernel.org. Most kernel developers monitor this > e-mail list, and can comment on your changes. > > Do not send more than 15 patches at once to the vger mailing lists!!! > > Linus Torvalds is the final arbiter of all changes accepted into the > Linux kernel. His e-mail address is . > He gets a lot of e-mail, so typically you should do your best to -avoid- > sending him e-mail. > " > > Anyway, I appreciate your notifiction and I will fix this errors. > > Best, > Lennox > > > 2013/9/16 Guenter Roeck : >> On Sat, Sep 14, 2013 at 05:42:07PM +0800, Lennox Wu wrote: >>> Hi Linus, >>> Please pull these updates for S+core architecture. These updates include >>> updating information of maintainers, fix some trivial errors, and add >>> a necessary function for supporting ipv6. >>> >>> The following changes since commit bdbdfdef5766c2a60185e946df242f1bc0d37c09 >>> >>> Merge tag 'hwmon-for-linus' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging >>> (Fri Sep 13 10:58:41 2013 -0700) >>> >>> on >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> >>> >>> For you to fetch changes up to 969f99168b9dff2f6cc07cdf14255178d4397c4f >>> >>> g...@github.com:sctscore/official-linux.git tags/branch-linus-20130914 >>> >>> Best, >>> Lennox Wu >>> >> Your e-mail is not signed. You don't even have a pgp key as far as >> I can see, at least not one associated with your e-mail address. >> How do you expect anyone to establish your identity ? >> >> In addition to that, the tag in your repository is not signed and >> does not contain a summary of your changes. Your patches do not >> have a Signed-off-by: tag. The pull message below appears to be >> hand-edited and does not match an auto-generated pull request >> (which should have given you a hint that the commit logs have >> a problem). >> >> You did not even copy Linus on this e-mail. Do you really think >> he would even notice your pull request, much less apply it ? >> >> Guenter >> >>> --- >>> Summary these commits: >>> 1. Fix some trivial errors for successfully compiling the latest >>> version Linux kernel. >>> 2. Provide necessary function for support IPV6. >>> 3. Update the information of maintainers. >>> >>> Lennox Wu (8): >>> score : Update the information of Score maintainers >>> score : Implement the function csum_ipv6_magic >>> score : arch/score/kernel/entry.S: fix wrong instructions >>> score : arch/score/kernel/process.c : fix some typos >>> score : Modify the MAKEFILE of Score >>> >>> MAINTAINERS |4 +- >>> arch/score/Kconfig|4 ++ >>> arch/score/Makefile |4 +- >>> arch/score/include/asm/checksum.h | 93 >>> - >>> arch/score/include/asm/io.h |1 - >>> arch/score/include/asm/pgalloc.h |2 +- >>> arch/score/kernel/entry.S |4 +- >>> arch/score/kernel/process.c |4 +- >>> 8 files changed, 64 insertions(+), 52 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/ >>> >>> >>> -- 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: linux-next: manual merge of the vfs tree with the aio-direct tree
On 09/17/2013 09:00 PM, Al Viro wrote:
> On Wed, Sep 18, 2013 at 10:56:38AM +1000, Stephen Rothwell wrote:
>> Hi Al,
>>
>> Today's linux-next merge of the vfs tree got conflicts in fs/nfs/direct.c
>> and fs/nfs/file.c between commits b9517433d65d ("dio: Convert direct_IO
>> to use iov_iter"), a8431c667ae8 ("nfs: add support for read_iter,
>> write_iter") and a1b8ec384b73 ("nfs: simplify swap") from the aio-direct
>> tree and commit c18d1ec44f7a ("nfs: use %p[dD] instead of open-coded (and
>> often racy) equivalents") from the vfs tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Hrm... FWIW, I would greatly prefer to offload these printk patches to
> NFS and NFSD trees. Didn't get around to that yet, but...
>
> As for aio-direct... Two questions:
> * had anybody tried to measure the effect on branch predictor from
> introducing that method vector? Commit d6afd4c4 ("iov_iter: hide iovec
> details behind ops function pointers")
Any suggestions for a good benchmark?
> * WTF does aforementioned commit lack its author's s-o-b? The same
> goes for a lot of zab's commits in there...
That would be my bad. Zach's original patches had his s-o-b (w/an Oracle
email address). I'll add them back.
Shaggy
--
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] ARM: STi: remove unused Kconfig parameters
This patch proposes to remove the 'SOC_STIH415' and 'SOC_STIH416' parameters, which are used nowhere else in the source code and Makefiles. Will they be needed in code that hasn't been submitted yet? Signed-off-by: Michael Opdenacker --- arch/arm/mach-sti/Kconfig | 23 --- 1 file changed, 23 deletions(-) diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig index 835833e..bef1a9f 100644 --- a/arch/arm/mach-sti/Kconfig +++ b/arch/arm/mach-sti/Kconfig @@ -21,26 +21,3 @@ menuconfig ARCH_STI for discovery More information at Documentation/arm/STiH41x and at Documentation/devicetree - - -if ARCH_STI - -config SOC_STIH415 - bool "STiH415 STMicroelectronics Consumer Electronics family" - default y - help - This enables support for STMicroelectronics Digital Consumer - Electronics family StiH415 parts, primarily targetted at set-top-box - and other digital audio/video applications using Flattned Device - Trees. - -config SOC_STIH416 - bool "STiH416 STMicroelectronics Consumer Electronics family" - default y - help - This enables support for STMicroelectronics Digital Consumer - Electronics family StiH416 parts, primarily targetted at set-top-box - and other digital audio/video applications using Flattened Device - Trees. - -endif -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Keyrings patches
On Tue, 2013-09-17 at 14:55 +0100, David Howells wrote: > There's a slight change upstream that means that my patchset needs > regenerating (the initconst changes). Can you bring your -next branch up to > date with linus/master so that I can rebase on top of it? Once -rc1 is out, James normally rebases linux-security/next. He's probably en route to LSS. Mimi -- 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-next: build failure after merge of the gpio tree
Hi Linus,
After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpio/gpio-pcf857x.c: In function 'pcf857x_irq_domain_map':
drivers/gpio/gpio-pcf857x.c:206:2: error: implicit declaration of function
'set_irq_flags' [-Werror=implicit-function-declaration]
set_irq_flags(virq, IRQF_VALID);
^
drivers/gpio/gpio-pcf857x.c:206:22: error: 'IRQF_VALID' undeclared (first use
in this function)
set_irq_flags(virq, IRQF_VALID);
^
Caused by commit 21fd3cd1874a ("gpio: pcf857x: call the gpio user handler
iff gpio_to_irq is done").
set_irq_flags() only exists on arm (and arm64).
I have used the gpio tree from next-20130917 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpg9GKKdBDoM.pgp
Description: PGP signature
Re: "memory" binding issues
On Tue, Sep 17, 2013 at 02:08:33PM -0700, Frank Rowand wrote: > On 9/17/2013 9:43 AM, Olof Johansson wrote: > > On Tue, Sep 17, 2013 at 09:56:39AM +0200, Tomasz Figa wrote: > >> I'm afraid that I must disagree. For consistency I'd rather go with what > >> Ben said. Please see ePAPR chapter 2.2.1.1, which clearly defines how > >> nodes should be named. > > > > 2.2.1.1 is there to point out that unit address _has_ to reflect reg. > > > > 2.2.3 says that unit addresses can be omitted. > > 2.2.3 is talking about path names. > > 2.2.1.1 is talking about node names. > > 2.2.1.1 _does_ require the unit address in the node name, 2.2.3 does not > remove that requirement. Certainly the recommendation I've been giving from the early days of ePAPR has been that a node should have a unit address if and only if it has a 'reg' property. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpPcxUUztukr.pgp Description: PGP signature
[PATCH V2] ahci: Changing two module params with static and __read_mostly
Here module parameters ahci_em_messages and devslp_idle_timeout can
be set as static and __read_mostly.
Signed-off-by: Liu, Chuansheng
---
drivers/ata/libahci.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index acfd0f7..b67086f 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -189,14 +189,15 @@ struct ata_port_operations ahci_pmp_retry_srst_ops = {
};
EXPORT_SYMBOL_GPL(ahci_pmp_retry_srst_ops);
-int ahci_em_messages = 1;
+static bool ahci_em_messages __read_mostly = true;
EXPORT_SYMBOL_GPL(ahci_em_messages);
-module_param(ahci_em_messages, int, 0444);
+module_param(ahci_em_messages, bool, 0444);
/* add other LED protocol types when they become supported */
MODULE_PARM_DESC(ahci_em_messages,
"AHCI Enclosure Management Message control (0 = off, 1 = on)");
-int devslp_idle_timeout = 1000;/* device sleep idle timeout in ms */
+/* device sleep idle timeout in ms */
+static int devslp_idle_timeout __read_mostly = 1000;
module_param(devslp_idle_timeout, int, 0644);
MODULE_PARM_DESC(devslp_idle_timeout, "device sleep idle timeout");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] clocksource: fix misleading comment for __clocksource_updatefreq_scale()
Functions clocksource_updatefreq_hz() and clocksource_updatefreq_khz()
mentioned in the comment of __clocksource_updatefreq_scale() do not exist.
As Thomas Gleixner's suggestion, I renamed the functions and the few call
sites because the underscores are completely meaningless.
Signed-off-by: Xie XiuQi
Cc: Thomas Gleixner
---
drivers/clocksource/cadence_ttc_timer.c | 2 +-
drivers/clocksource/em_sti.c| 2 +-
drivers/clocksource/sh_cmt.c| 2 +-
drivers/clocksource/sh_tmu.c| 2 +-
include/linux/clocksource.h | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/cadence_ttc_timer.c
b/drivers/clocksource/cadence_ttc_timer.c
index 4cbe28c..05f00e7 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -226,7 +226,7 @@ static int ttc_rate_change_clocksource_cb(struct
notifier_block *nb,
* Do whatever is necessary to maintain a proper time base
*
* I cannot find a way to adjust the currently used clocksource
-* to the new frequency. __clocksource_updatefreq_hz() sounds
+* to the new frequency. clocksource_updatefreq_hz() sounds
* good, but does not work. Not sure what's that missing.
*
* This approach works, but triggers two clocksource switches.
diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
index 4329a29..ccbb513 100644
--- a/drivers/clocksource/em_sti.c
+++ b/drivers/clocksource/em_sti.c
@@ -210,7 +210,7 @@ static int em_sti_clocksource_enable(struct clocksource *cs)
ret = em_sti_start(p, USER_CLOCKSOURCE);
if (!ret)
- __clocksource_updatefreq_hz(cs, p->rate);
+ clocksource_updatefreq_hz(cs, p->rate);
return ret;
}
diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
index 08d0c41..dc812c5 100644
--- a/drivers/clocksource/sh_cmt.c
+++ b/drivers/clocksource/sh_cmt.c
@@ -504,7 +504,7 @@ static int sh_cmt_clocksource_enable(struct clocksource *cs)
ret = sh_cmt_start(p, FLAG_CLOCKSOURCE);
if (!ret) {
- __clocksource_updatefreq_hz(cs, p->rate);
+ clocksource_updatefreq_hz(cs, p->rate);
p->cs_enabled = true;
}
return ret;
diff --git a/drivers/clocksource/sh_tmu.c b/drivers/clocksource/sh_tmu.c
index 78b8dae..be4ae3e 100644
--- a/drivers/clocksource/sh_tmu.c
+++ b/drivers/clocksource/sh_tmu.c
@@ -236,7 +236,7 @@ static int sh_tmu_clocksource_enable(struct clocksource *cs)
ret = sh_tmu_enable(p);
if (!ret) {
- __clocksource_updatefreq_hz(cs, p->rate);
+ clocksource_updatefreq_hz(cs, p->rate);
p->cs_enabled = true;
}
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index dbbf8aa..87e8aa0 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -314,12 +314,12 @@ static inline int clocksource_register_khz(struct
clocksource *cs, u32 khz)
return __clocksource_register_scale(cs, 1000, khz);
}
-static inline void __clocksource_updatefreq_hz(struct clocksource *cs, u32 hz)
+static inline void clocksource_updatefreq_hz(struct clocksource *cs, u32 hz)
{
__clocksource_updatefreq_scale(cs, 1, hz);
}
-static inline void __clocksource_updatefreq_khz(struct clocksource *cs, u32
khz)
+static inline void clocksource_updatefreq_khz(struct clocksource *cs, u32 khz)
{
__clocksource_updatefreq_scale(cs, 1000, khz);
}
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] x86_64: Add safe check in a.out loaders and some coding style
ia32_aout had no safe checks concerning the mmap and f_op in this module.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style and printk strings fixes.
Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.
Signed-off-by: Geyslan G. Bem
---
arch/x86/ia32/ia32_aout.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index bae3aba..15a8319 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -271,10 +271,17 @@ static int load_aout_binary(struct linux_binprm *bprm)
N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
N_TRSIZE(ex) || N_DRSIZE(ex) ||
i_size_read(file_inode(bprm->file)) <
- ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
return -ENOEXEC;
}
+ /*
+* Requires a mmap handler. This prevents people from using a.out
+* as part of an exploit attack against /proc-related vulnerabilities.
+*/
+ if (!bprm->file->f_op || !bprm->file->f_op->mmap)
+ return -ENOEXEC;
+
fd_offset = N_TXTOFF(ex);
/* Check initial limits. This avoids letting people circumvent
@@ -350,14 +357,13 @@ static int load_aout_binary(struct linux_binprm *bprm)
if ((fd_offset & ~PAGE_MASK) != 0 &&
time_after(jiffies, error_time + 5*HZ)) {
printk(KERN_WARNING
- "fd_offset is not page aligned. Please convert "
- "program: %s\n",
+ "fd_offset is not page aligned. Please convert
program: %s\n",
bprm->file->f_path.dentry->d_name.name);
error_time = jiffies;
}
#endif
- if (!bprm->file->f_op->mmap || (fd_offset & ~PAGE_MASK) != 0) {
+ if ((fd_offset & ~PAGE_MASK) != 0) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
read_code(bprm->file, N_TXTADDR(ex), fd_offset,
ex.a_text+ex.a_data);
@@ -424,10 +430,17 @@ static int load_aout_library(struct file *file)
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
i_size_read(file_inode(file)) <
- ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
goto out;
}
+ /*
+* Requires a mmap handler. This prevents people from using a.out
+* as part of an exploit attack against /proc-related vulnerabilities.
+*/
+ if (!file->f_op->mmap)
+ goto out;
+
if (N_FLAGS(ex))
goto out;
@@ -441,8 +454,7 @@ static int load_aout_library(struct file *file)
static unsigned long error_time;
if (time_after(jiffies, error_time + 5*HZ)) {
printk(KERN_WARNING
- "N_TXTOFF is not page aligned. Please convert "
- "library: %s\n",
+ "N_TXTOFF is not page aligned. Please convert
library: %s\n",
file->f_path.dentry->d_name.name);
error_time = jiffies;
}
--
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] audit: format user messages to size of MAX_AUDIT_MESSAGE_LENGTH
Messages of type AUDIT_USER_TTY were being formatted to 1024 octets,
truncating messages approaching MAX_AUDIT_MESSAGE_LENGTH (8970 octets).
Set the formatting to 8560 characters, given maximum estimates for prefix and
suffix budgets.
See the problem discussion:
https://www.redhat.com/archives/linux-audit/2009-January/msg00030.html
And the new size rationale:
https://www.redhat.com/archives/linux-audit/2013-September/msg00016.html
Test ~8k messages with:
auditctl -m "$(for i in $(seq -w 001 820);do echo -n "${i}0__";done)"
Reported-by: LC Bruzenak
Reported-by: Justin Stephenson
Signed-off-by: Richard Guy Briggs
---
kernel/audit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 91e53d0..939cff1 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -715,7 +715,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct
nlmsghdr *nlh)
}
audit_log_common_recv_msg(, msg_type);
if (msg_type != AUDIT_USER_TTY)
- audit_log_format(ab, " msg='%.1024s'",
+ audit_log_format(ab, " msg='%.8560s'",
(char *)data);
else {
int size;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] x86: Useless inode var and Coding style fixes
file size read only one time: useless prior value allocation.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style and printk strings fixes.
Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.
Signed-off-by: Geyslan G. Bem
---
fs/binfmt_aout.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index 89dec7f..a4af504 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -142,7 +142,8 @@ static int set_brk(unsigned long start, unsigned long end)
* memory and creates the pointer tables from them, and puts their
* addresses on the "stack", returning the new stack pointer value.
*/
-static unsigned long __user *create_aout_tables(char __user *p, struct
linux_binprm * bprm)
+static unsigned long __user *create_aout_tables(char __user *p,
+ struct linux_binprm *bprm)
{
char __user * __user *argv;
char __user * __user *envp;
@@ -213,7 +214,8 @@ static int load_aout_binary(struct linux_binprm * bprm)
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
N_TRSIZE(ex) || N_DRSIZE(ex) ||
- i_size_read(file_inode(bprm->file)) <
ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ i_size_read(file_inode(bprm->file)) <
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
return -ENOEXEC;
}
@@ -299,12 +301,12 @@ static int load_aout_binary(struct linux_binprm * bprm)
if ((fd_offset & ~PAGE_MASK) != 0 && printk_ratelimit())
{
- printk(KERN_WARNING
+ printk(KERN_WARNING
"fd_offset is not page aligned. Please convert
program: %s\n",
bprm->file->f_path.dentry->d_name.name);
}
- if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) {
+ if ((fd_offset & ~PAGE_MASK) != 0) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
read_code(bprm->file, N_TXTADDR(ex), fd_offset,
ex.a_text + ex.a_data);
@@ -350,14 +352,11 @@ beyond_if:
static int load_aout_library(struct file *file)
{
- struct inode * inode;
unsigned long bss, start_addr, len;
unsigned long error;
int retval;
struct exec ex;
- inode = file_inode(file);
-
retval = -ENOEXEC;
error = kernel_read(file, 0, (char *) , sizeof(ex));
if (error != sizeof(ex))
@@ -366,7 +365,8 @@ static int load_aout_library(struct file *file)
/* We come in here for the regular a.out style of shared libraries */
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
- i_size_read(inode) <
ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ i_size_read(file_inode(file)) <
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
goto out;
}
@@ -374,7 +374,7 @@ static int load_aout_library(struct file *file)
* Requires a mmap handler. This prevents people from using a.out
* as part of an exploit attack against /proc-related vulnerabilities.
*/
- if (!file->f_op || !file->f_op->mmap)
+ if (!file->f_op->mmap)
goto out;
if (N_FLAGS(ex))
@@ -388,12 +388,12 @@ static int load_aout_library(struct file *file)
if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
if (printk_ratelimit())
{
- printk(KERN_WARNING
+ printk(KERN_WARNING
"N_TXTOFF is not page aligned. Please convert
library: %s\n",
file->f_path.dentry->d_name.name);
}
vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
-
+
read_code(file, start_addr, N_TXTOFF(ex),
ex.a_text + ex.a_data);
retval = 0;
--
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/
RE: [PATCH] ahci: Changing two module params with static and __read_mostly
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Wednesday, September 18, 2013 12:24 AM
> To: Liu, Chuansheng
> Cc: t...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ahci: Changing two module params with static and
> __read_mostly
>
> On Wed, 2013-09-18 at 00:48 +0800, Chuansheng Liu wrote:
> > Here module parameters ahci_em_messages and devslp_idle_timeout can
> > be set as static and __read_mostly.
> >
> > Signed-off-by: Liu, Chuansheng
> > ---
> > drivers/ata/libahci.c |5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> []
> > @@ -189,14 +189,15 @@ struct ata_port_operations
> ahci_pmp_retry_srst_ops = {
> > };
> > EXPORT_SYMBOL_GPL(ahci_pmp_retry_srst_ops);
> >
> > -int ahci_em_messages = 1;
> > +static int ahci_em_messages __read_mostly = 1;
>
> This one could also be converted to
> static bool ahci_em_messages __read_mostly = true;
>
Thanks, will update one new patch.
--
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] x86: Useless inode var and Coding style fixes
On 09/17/2013 07:22 PM, Geyslan G. Bem wrote: > file size read only one time: useless prior value allocation. > It's not necessary to verify f_op in the load_aout_library, since the > prior kernel_read/vfs_read function already does. > Coding style and printk strings fixes. > > Tested using qemu, a handcrafted a.out binary and a a.out linked with a > cross-compiled ld. > > Signed-off-by: Geyslan G. Bem > --- > fs/binfmt_aout.c | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) This is not an x86 patch. The other one is only because we effectively have a copy of the a.out code in the ia32 directory, but it too can go through the generic route with my ack. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] x86: Useless inode var and Coding style fixes
file size read only one time: useless prior value allocation.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style and printk strings fixes.
Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.
Signed-off-by: Geyslan G. Bem
---
fs/binfmt_aout.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index 89dec7f..a4af504 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -142,7 +142,8 @@ static int set_brk(unsigned long start, unsigned long end)
* memory and creates the pointer tables from them, and puts their
* addresses on the "stack", returning the new stack pointer value.
*/
-static unsigned long __user *create_aout_tables(char __user *p, struct
linux_binprm * bprm)
+static unsigned long __user *create_aout_tables(char __user *p,
+ struct linux_binprm *bprm)
{
char __user * __user *argv;
char __user * __user *envp;
@@ -213,7 +214,8 @@ static int load_aout_binary(struct linux_binprm * bprm)
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
N_TRSIZE(ex) || N_DRSIZE(ex) ||
- i_size_read(file_inode(bprm->file)) <
ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ i_size_read(file_inode(bprm->file)) <
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
return -ENOEXEC;
}
@@ -299,12 +301,12 @@ static int load_aout_binary(struct linux_binprm * bprm)
if ((fd_offset & ~PAGE_MASK) != 0 && printk_ratelimit())
{
- printk(KERN_WARNING
+ printk(KERN_WARNING
"fd_offset is not page aligned. Please convert
program: %s\n",
bprm->file->f_path.dentry->d_name.name);
}
- if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) {
+ if ((fd_offset & ~PAGE_MASK) != 0) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
read_code(bprm->file, N_TXTADDR(ex), fd_offset,
ex.a_text + ex.a_data);
@@ -350,14 +352,11 @@ beyond_if:
static int load_aout_library(struct file *file)
{
- struct inode * inode;
unsigned long bss, start_addr, len;
unsigned long error;
int retval;
struct exec ex;
- inode = file_inode(file);
-
retval = -ENOEXEC;
error = kernel_read(file, 0, (char *) , sizeof(ex));
if (error != sizeof(ex))
@@ -366,7 +365,8 @@ static int load_aout_library(struct file *file)
/* We come in here for the regular a.out style of shared libraries */
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
- i_size_read(inode) <
ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ i_size_read(file_inode(file)) <
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
goto out;
}
@@ -374,7 +374,7 @@ static int load_aout_library(struct file *file)
* Requires a mmap handler. This prevents people from using a.out
* as part of an exploit attack against /proc-related vulnerabilities.
*/
- if (!file->f_op || !file->f_op->mmap)
+ if (!file->f_op->mmap)
goto out;
if (N_FLAGS(ex))
@@ -388,12 +388,12 @@ static int load_aout_library(struct file *file)
if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
if (printk_ratelimit())
{
- printk(KERN_WARNING
+ printk(KERN_WARNING
"N_TXTOFF is not page aligned. Please convert
library: %s\n",
file->f_path.dentry->d_name.name);
}
vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
-
+
read_code(file, start_addr, N_TXTOFF(ex),
ex.a_text + ex.a_data);
retval = 0;
--
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 1/2] x86_64: Add safe check in a.out loaders and some coding style
ia32_aout had no safe checks concerning the mmap and f_op in this module.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style and printk strings fixes.
Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.
Signed-off-by: Geyslan G. Bem
---
arch/x86/ia32/ia32_aout.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index bae3aba..15a8319 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -271,10 +271,17 @@ static int load_aout_binary(struct linux_binprm *bprm)
N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
N_TRSIZE(ex) || N_DRSIZE(ex) ||
i_size_read(file_inode(bprm->file)) <
- ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
return -ENOEXEC;
}
+ /*
+* Requires a mmap handler. This prevents people from using a.out
+* as part of an exploit attack against /proc-related vulnerabilities.
+*/
+ if (!bprm->file->f_op || !bprm->file->f_op->mmap)
+ return -ENOEXEC;
+
fd_offset = N_TXTOFF(ex);
/* Check initial limits. This avoids letting people circumvent
@@ -350,14 +357,13 @@ static int load_aout_binary(struct linux_binprm *bprm)
if ((fd_offset & ~PAGE_MASK) != 0 &&
time_after(jiffies, error_time + 5*HZ)) {
printk(KERN_WARNING
- "fd_offset is not page aligned. Please convert "
- "program: %s\n",
+ "fd_offset is not page aligned. Please convert
program: %s\n",
bprm->file->f_path.dentry->d_name.name);
error_time = jiffies;
}
#endif
- if (!bprm->file->f_op->mmap || (fd_offset & ~PAGE_MASK) != 0) {
+ if ((fd_offset & ~PAGE_MASK) != 0) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
read_code(bprm->file, N_TXTADDR(ex), fd_offset,
ex.a_text+ex.a_data);
@@ -424,10 +430,17 @@ static int load_aout_library(struct file *file)
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
i_size_read(file_inode(file)) <
- ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+ ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
goto out;
}
+ /*
+* Requires a mmap handler. This prevents people from using a.out
+* as part of an exploit attack against /proc-related vulnerabilities.
+*/
+ if (!file->f_op->mmap)
+ goto out;
+
if (N_FLAGS(ex))
goto out;
@@ -441,8 +454,7 @@ static int load_aout_library(struct file *file)
static unsigned long error_time;
if (time_after(jiffies, error_time + 5*HZ)) {
printk(KERN_WARNING
- "N_TXTOFF is not page aligned. Please convert "
- "library: %s\n",
+ "N_TXTOFF is not page aligned. Please convert
library: %s\n",
file->f_path.dentry->d_name.name);
error_time = jiffies;
}
--
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/
Re: linux-next: manual merge of the vfs tree with the aio-direct tree
On Wed, Sep 18, 2013 at 10:56:38AM +1000, Stephen Rothwell wrote:
> Hi Al,
>
> Today's linux-next merge of the vfs tree got conflicts in fs/nfs/direct.c
> and fs/nfs/file.c between commits b9517433d65d ("dio: Convert direct_IO
> to use iov_iter"), a8431c667ae8 ("nfs: add support for read_iter,
> write_iter") and a1b8ec384b73 ("nfs: simplify swap") from the aio-direct
> tree and commit c18d1ec44f7a ("nfs: use %p[dD] instead of open-coded (and
> often racy) equivalents") from the vfs tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Hrm... FWIW, I would greatly prefer to offload these printk patches to
NFS and NFSD trees. Didn't get around to that yet, but...
As for aio-direct... Two questions:
* had anybody tried to measure the effect on branch predictor from
introducing that method vector? Commit d6afd4c4 ("iov_iter: hide iovec
details behind ops function pointers")
* WTF does aforementioned commit lack its author's s-o-b? The same
goes for a lot of zab's commits in there...
--
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] audit: avoid soft lockup in audit_log_start()
On Tue, Sep 17, 2013 at 03:28:42PM -0700, Andrew Morton wrote:
> On Tue, 10 Sep 2013 12:03:25 -0400 Eric Paris wrote:
>
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -1215,9 +1215,10 @@ struct audit_buffer *audit_log_start(struct
> > > audit_context *ctx, gfp_t gfp_mask,
> > >
> > > sleep_time = timeout_start +
> > > audit_backlog_wait_time -
> > > jiffies;
> > > - if ((long)sleep_time > 0)
> > > + if ((long)sleep_time > 0) {
> > > wait_for_auditd(sleep_time);
> > > - continue;
> > > + continue;
> > > + }
> > > }
> > > if (audit_rate_check() && printk_ratelimit())
> > > printk(KERN_WARNING
> >
> > I think this is the right(ish) fix, at least it gets at the real bug.
> > 829199197a430dade2519d54f5545c4a094393b8 definitely is the problem.
>
> um, which idiot wrote that?
Heh...
> Thngs are somewhat foggy at present. I have two patches from
> Dan/Chuck:
>
> Subject: audit: fix soft lockups due to loop in audit_log_start() wh,en
> audit_backlog_limit exceeded
> Subject: audit: two efficiency fixes for audit mechanism
I have a patchset very similar to the first and breaking up the second,
with some added bits to address other related issues I'll post RSN...
> and two from Luiz:
>
> Subject: audit: flush_hold_queue(): don't drop queued SKBs
> Subject: audit: kaudit_send_skb(): make non-blocking call to netlink_unicast()
>
> and now a protopatch from Konstantin which eparis likes.
>
> So, umm, guys, can you please devote a bit of time to working out what
> we should do here?
It is coming... I'm hearing reports from others of the same bug, so it
is getting around...
- RGB
--
Richard Guy Briggs
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545
--
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/4] usb: musb: Call atomic_notifier_call_chain when status is changed
On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > More power supply drivers depends on vbus events and
> > > > > without it they not working. Power supply drivers using
> > > > > usb_register_notifier, so to deliver events it is
> > > > > needed to call atomic_notifier_call_chain.
> > > > >
> > > > > So without atomic notifier power supply driver isp1704
> > > > > not retrieving vbus status and reporting bogus values
> > > > > to userspace and also to board platform data functions.
> > > > > Without proper data charger drivers trying to charge
> > > > > battery also when charger is disconnected or do not
> > > > > start charging when wallcharger connects.
> > > > >
> > > > > Atomic notifier in musb driver was used before v3.5 and
> > > > > was replaced with omap mailbox. This patch adding
> > > > > atomic_notifier_call_chain call from function
> > > > > omap_musb_set_mailbox.
> > > > >
> > > > > Signed-off-by: Pali Rohár
> > > > > ---
> > > > >
> > > > > drivers/usb/musb/omap2430.c |3 +++
> > > > > drivers/usb/phy/phy-twl4030-usb.c |2 ++
> > > > > 2 files changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > @@ -305,6 +305,9 @@ static void
> > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > >
> > > > > default:
> > > > > dev_dbg(dev, "ID float\n");
> > > > >
> > > > > }
> > > > >
> > > > > +
> > > > > + atomic_notifier_call_chain(>xceiv->notifier,
> > > > > + musb->xceiv->last_event, NULL);
> > > >
> > > > let's add a wrapper for this:
> > > >
> > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > unsigned val, void *v) {
> > > >
> > > > return atomic_notifier_call_chain(>notifier, val, v);
> > > >
> > > > }
> > >
> > > Where to add this wrapper? To omap2430.c? or some include
> > > file?
> >
> >
> >
> > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > 8f78d2d..efe6155 100644
> > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > > platform_device *pdev)
> > > > >
> > > > > if (device_create_file(>dev, _attr_vbus))
> > > > >
> > > > > dev_warn(>dev, "could not create sysfs
> > > > > file\n");
> > > > >
> > > > > + ATOMIC_INIT_NOTIFIER_HEAD(>phy.notifier);
> > > >
> > > > BTW, this is a bugfix, send separately.
> > >
> > > What to send separately?
> > >
> > > This full patch 1/4 is bugfix. And I did not understand what
> > > you want. Maybe it could be easier for you to apply this
> > > small 3+2 lines patch how you need.
> >
> > This hunk here (initializaing notifier head) is a separate bug
> > fix and needs its own patch.
>
> So will you do that? Or it is needed to resend this one line hunk
> again in new email again?
new patch, new email
--
balbi
signature.asc
Description: Digital signature
Re: [GIT PULL] Keyrings patches
Hi Dave, On Tue, 17 Sep 2013 14:55:49 +0100 David Howells wrote: > > There's a slight change upstream that means that my patchset needs > regenerating (the initconst changes). Can you bring your -next branch up to > date with linus/master so that I can rebase on top of it? Is there some reason that those fixups cannot be done in a merge commit? i.e. are they more than simple text updates? /me thinks that most rebases people do can be better done (and documented) as merges. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFPMoSTFTzZ.pgp Description: PGP signature
Re: [PATCH] clocksource: fix comment for __clocksource_updatefreq_scale
On 2013/9/18 2:57, Thomas Gleixner wrote:
> On Tue, 17 Sep 2013, Xie XiuQi wrote:
>
>> The functions clocksource_updatefreq_hz() and clocksource_updatefreq_khz()
>> do not exist, The proper ones are __clocksource_updatefreq_hz() and
>> __clocksource_updatefreq_khz().
>
> I'd rather rename the functions and the few call sites because the
> underscores are completely meaningless.
That's a good idea, thanks. I'll update this patch and send later.
>
> Thanks,
>
> tglx
>
>> Signed-off-by: Xie XiuQi
>> ---
>> kernel/time/clocksource.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
>> index 50a8736..d2f6ddc 100644
>> --- a/kernel/time/clocksource.c
>> +++ b/kernel/time/clocksource.c
>> @@ -714,7 +714,8 @@ static void clocksource_enqueue(struct clocksource *cs)
>> * This should only be called from the clocksource->enable() method.
>> *
>> * This *SHOULD NOT* be called directly! Please use the
>> - * clocksource_updatefreq_hz() or clocksource_updatefreq_khz helper
>> functions.
>> + * __clocksource_updatefreq_hz() or __clocksource_updatefreq_khz helper
>> + * functions.
>> */
>> void __clocksource_updatefreq_scale(struct clocksource *cs, u32 scale, u32
>> freq)
>> {
>> --
>> 1.8.2.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] usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC
Hi, On Mon, Sep 09, 2013 at 08:24:24AM -0700, Greg Kroah-Hartman wrote: > On Mon, Sep 09, 2013 at 07:33:31AM +0200, Andreas Larsson wrote: > > On 2013-08-28 11:02, Andreas Larsson wrote: > > > On 2013-08-12 16:05, Andreas Larsson wrote: > > >> This adds an UDC driver for GRUSBDC USB Device Controller cores > > >> available in the > > >> GRLIB VHDL IP core library. The driver only supports DMA mode. > > > > > > Any comments? It would be great to get feedback soon in case some things > > > need to be changed for this driver to be accepted. Thanks! > > > > Anyone? > > > > Is there anything holding it back from being accepted into mainline? > > This is the middle of the merge window, nothing can be accepted at the > moment, please wait until 3.12-rc1 comes out and our trees open up again > to expect a response. I'll review this one tomorrow or day after. -- balbi signature.asc Description: Digital signature
Re: Fix style in s3c-hsotg.c
On Wed, Sep 18, 2013 at 12:04:27AM +0200, Pavel Machek wrote:
> On Tue 2013-09-17 10:42:30, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Sep 02, 2013 at 03:58:32PM +0200, Pavel Machek wrote:
> > > Hi!
> > >
> > > checkpatch.pl has some valid complaints about style in s3c-hsotg.c :
> > > macro with if should be really enclosed in do {} while, and puts is
> > > going to be slightly faster.
> > >
> > > Here's suggested patch. I don't have the hardware, so it is completely
> > > untested.
> > >
> > > Signed-off-by: Pavel Machek,
> >
> > this is not how you send a patch, please read
> > Documentation/SubmittingPatches
>
> Have you considered possibility that this is how you nudge maintainer
> into fix their coding style?
cute...
Seriously though, read that file, you're commit log has garbage in it
which shouldn't go to git history.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] EFI: use nr_tables param directly in efi_config_init
On 09/17/13 at 04:49pm, Matt Fleming wrote:
> On Thu, 12 Sep, at 04:45:28PM, Dave Young wrote:
> > efi_config_init has the parameter nr_tables. Just use it instead of
> > dereference efi.systab->nr_tables.
> >
> > Signed-off-by: Dave Young
> > ---
> > arch/x86/platform/efi/efi.c |7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > --- linux-2.6.orig/arch/x86/platform/efi/efi.c
> > +++ linux-2.6/arch/x86/platform/efi/efi.c
> > @@ -599,7 +599,7 @@ static int __init efi_config_init(u64 ta
> >
> > tablep = config_tables;
> > pr_info("");
> > - for (i = 0; i < efi.systab->nr_tables; i++) {
> > + for (i = 0; i < nr_tables; i++) {
> > efi_guid_t guid;
> > unsigned long table;
> >
> > @@ -612,8 +612,7 @@ static int __init efi_config_init(u64 ta
> > if (table64 >> 32) {
> > pr_cont("\n");
> > pr_err("Table located above 4GB, disabling
> > EFI.\n");
> > - early_iounmap(config_tables,
> > - efi.systab->nr_tables * sz);
> > + early_iounmap(config_tables, nr_tables * sz);
> > return -EINVAL;
> > }
> > #endif
> > @@ -648,7 +647,7 @@ static int __init efi_config_init(u64 ta
> > tablep += sz;
> > }
> > pr_cont("\n");
> > - early_iounmap(config_tables, efi.systab->nr_tables * sz);
> > + early_iounmap(config_tables, nr_tables * sz);
> > return 0;
> > }
>
> Thanks Dave, but this patch should no longer be necessary because of the
> changes sitting in the 'next' branch at,
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
Ok, no problem. Thanks for letting me know.
Will write patches based on the above tree next time.
>
> --
> Matt Fleming, Intel Open Source Technology Center
--
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] block: change config option name for cmdline partition parsing
Recently added commit bab55417b10c95e6bff8cea315c315adfa009487
("block: support embedded device command line partition") introduced
CONFIG_CMDLINE_PARSER. However, that name is too generic and sounds
like it enables/disables generic kernel boot arg processing, when it
really is block specific.
Before this option becomes a part of a full/final release, add the
BLK_ prefix to it so that it is clear in absence of any other context
that it is block specific.
In addition, fix up the following less critical items:
- help text was not really at all helpful.
- index file for Documentation was not updated
- add the new arg to Documentation/kernel-parameters.txt
- clarify wording in source comments
Cc: Jens Axboe
Cc: Cai Zhiyong
Cc: Wei Yongjun
Cc: Andrew Morton
Signed-off-by: Paul Gortmaker
---
Documentation/block/00-INDEX | 2 ++
Documentation/block/cmdline-partition.txt | 8
Documentation/kernel-parameters.txt | 4
block/Kconfig | 9 +++--
block/Makefile| 2 +-
block/partitions/Kconfig | 4 ++--
block/partitions/cmdline.c| 8
7 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX
index d18ecd8..929d990 100644
--- a/Documentation/block/00-INDEX
+++ b/Documentation/block/00-INDEX
@@ -6,6 +6,8 @@ capability.txt
- Generic Block Device Capability (/sys/block//capability)
cfq-iosched.txt
- CFQ IO scheduler tunables
+cmdline-partition.txt
+ - how to specify block device partitions on kernel command line
data-integrity.txt
- Block data integrity
deadline-iosched.txt
diff --git a/Documentation/block/cmdline-partition.txt
b/Documentation/block/cmdline-partition.txt
index 2bbf4cc..525b9f6 100644
--- a/Documentation/block/cmdline-partition.txt
+++ b/Documentation/block/cmdline-partition.txt
@@ -1,9 +1,9 @@
-Embedded device command line partition
+Embedded device command line partition parsing
=
-Read block device partition table from command line.
-The partition used for fixed block device (eMMC) embedded device.
-It is no MBR, save storage space. Bootloader can be easily accessed
+Support for reading the block device partition table from the command line.
+It is typically used for fixed block (eMMC) embedded devices.
+It has no MBR, so saves storage space. Bootloader can be easily accessed
by absolute address of data on the block device.
Users can easily change the partition.
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 1a036cd9..9e5ca2a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -480,6 +480,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format: ,,
See header of drivers/net/hamradio/baycom_ser_hdx.c.
+ blkdevparts=Manual partition parsing of block device(s) for
+ embedded devices based on command line input.
+ See Documentation/block/cmdline-partition.txt
+
boot_delay= Milliseconds to delay each printk during boot.
Values larger than 10 seconds (1) are changed to
no delay (0).
diff --git a/block/Kconfig b/block/Kconfig
index 7f38e40..2429515 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -99,11 +99,16 @@ config BLK_DEV_THROTTLING
See Documentation/cgroups/blkio-controller.txt for more information.
-config CMDLINE_PARSER
+config BLK_CMDLINE_PARSER
bool "Block device command line partition parser"
default n
---help---
- Parsing command line, get the partitions information.
+ Enabling this option allows you to specify the partition layout from
+ the kernel boot args. This is typically of use for embedded devices
+ which don't otherwise have any standardized method for listing the
+ partitions on a block device.
+
+ See Documentation/block/cmdline-partition.txt for more information.
menu "Partition Types"
diff --git a/block/Makefile b/block/Makefile
index 4fa4be5..671a83d 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -18,4 +18,4 @@ obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched.o
obj-$(CONFIG_BLOCK_COMPAT) += compat_ioctl.o
obj-$(CONFIG_BLK_DEV_INTEGRITY)+= blk-integrity.o
-obj-$(CONFIG_CMDLINE_PARSER) += cmdline-parser.o
+obj-$(CONFIG_BLK_CMDLINE_PARSER) += cmdline-parser.o
diff --git a/block/partitions/Kconfig b/block/partitions/Kconfig
index 87a3208..9b29a99 100644
--- a/block/partitions/Kconfig
+++ b/block/partitions/Kconfig
@@ -263,7 +263,7 @@ config SYSV68_PARTITION
config CMDLINE_PARTITION
bool "Command line partition support" if PARTITION_ADVANCED
- select CMDLINE_PARSER
+
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_drv.h between commit 6e1b4fdad515 ("drm/i915:
Delay disabling of VGA memory until vgacon->fbcon handoff is done") from
Linus' tree and commit eb14cb747bc5 ("drm/i915: Add state readout and
checking for has_dp_encoder and dp_m_n") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 28cae80,b85354f..000
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -793,6 -814,13 +815,14 @@@ extern void hsw_pc8_disable_interrupts(
extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
+extern void i915_disable_vga_mem(struct drm_device *dev);
+ extern void intel_dp_get_m_n(struct intel_crtc *crtc,
+struct intel_crtc_config *pipe_config);
+ extern int intel_dotclock_calculate(int link_freq,
+ const struct intel_link_m_n *m_n);
+ extern void ironlake_check_encoder_dotclock(const struct intel_crtc_config
*pipe_config,
+ int dotclock);
+
+ extern bool intel_crtc_active(struct drm_crtc *crtc);
#endif /* __INTEL_DRV_H__ */
pgp10HD5Az3AU.pgp
Description: PGP signature
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 7dc19d5affd7 ("drivers:
convert shrinkers to new count/scan API") from the tree and commit
e656a6cba0fe ("drm/i915: inline vma_create into lookup_or_create_vma")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index df9253d,d00d24f..000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4886,61 -4912,3 +4940,37 @@@ unsigned long i915_gem_obj_size(struct
return 0;
}
+
+static unsigned long
+i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(shrinker,
+ struct drm_i915_private,
+ mm.inactive_shrinker);
+ struct drm_device *dev = dev_priv->dev;
+ int nr_to_scan = sc->nr_to_scan;
+ unsigned long freed;
+ bool unlock = true;
+
+ if (!mutex_trylock(>struct_mutex)) {
+ if (!mutex_is_locked_by(>struct_mutex, current))
+ return 0;
+
+ if (dev_priv->mm.shrinker_no_lock_stealing)
+ return 0;
+
+ unlock = false;
+ }
+
+ freed = i915_gem_purge(dev_priv, nr_to_scan);
+ if (freed < nr_to_scan)
+ freed += __i915_gem_shrink(dev_priv, nr_to_scan,
+ false);
+ if (freed < nr_to_scan)
+ freed += i915_gem_shrink_all(dev_priv);
+
+ if (unlock)
+ mutex_unlock(>struct_mutex);
+ return freed;
+}
-
- struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
-struct i915_address_space *vm)
- {
- struct i915_vma *vma;
- list_for_each_entry(vma, >vma_list, vma_link)
- if (vma->vm == vm)
- return vma;
-
- return NULL;
- }
-
- struct i915_vma *
- i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
- struct i915_address_space *vm)
- {
- struct i915_vma *vma;
-
- vma = i915_gem_obj_to_vma(obj, vm);
- if (!vma)
- vma = i915_gem_vma_create(obj, vm);
-
- return vma;
- }
pgp2pyZAxZl16.pgp
Description: PGP signature
Re: [RFC PATCH RESEND] mm: munlock: Prevent walking off the end of a pagetable in no-pmd configuration
On 09/17/2013 10:22 PM, Vlastimil Babka wrote:
> The function __munlock_pagevec_fill() introduced in commit 7a8010cd3
> ("mm: munlock: manual pte walk in fast path instead of follow_page_mask()")
> uses pmd_addr_end() for restricting its operation within current page table.
> This is insufficient on architectures/configurations where pmd is folded
> and pmd_addr_end() just returns the end of the full range to be walked. In
> this case, it allows pte++ to walk off the end of a page table resulting in
> unpredictable behaviour.
>
> This patch fixes the function by using pgd_addr_end() and pud_addr_end()
> before pmd_addr_end(), which will yield correct page table boundary on all
> configurations. This is similar to what existing page walkers do when walking
> each level of the page table.
>
> Additionaly, the patch clarifies a comment for get_locked_pte() call in the
> function.
>
> Reported-by: Fengguang Wu
> Cc: Jörn Engel
> Cc: Mel Gorman
> Cc: Michel Lespinasse
> Cc: Hugh Dickins
> Cc: Rik van Riel
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Signed-off-by: Vlastimil Babka
> ---
> mm/mlock.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mlock.c b/mm/mlock.c
> index d638026..758c0fc 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -379,10 +379,14 @@ static unsigned long __munlock_pagevec_fill(struct
> pagevec *pvec,
>
> /*
>* Initialize pte walk starting at the already pinned page where we
> - * are sure that there is a pte.
> + * are sure that there is a pte, as it was pinned under the same
> + * mmap_sem write op.
>*/
> pte = get_locked_pte(vma->vm_mm, start, );
> - end = min(end, pmd_addr_end(start, end));
> + /* Make sure we do not cross the page table boundary */
> + end = pgd_addr_end(start, end);
> + end = pud_addr_end(start, end);
> + end = pmd_addr_end(start, end);
>
Nitpick, how about unfolding pmd_addr_end(start, end) directly? Like:
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -376,13 +376,14 @@ static unsigned long __munlock_pagevec_fill(struct
pagevec *pvec,
{
pte_t *pte;
spinlock_t *ptl;
+ unsigned long pmd_end = (start + PMD_SIZE) & PMD_MASK;
+ end = (pmd_end - 1 < end - 1) ? pmd_end : end;
/*
* Initialize pte walk starting at the already pinned page where we
* are sure that there is a pte.
*/
pte = get_locked_pte(vma->vm_mm, start, );
- end = min(end, pmd_addr_end(start, end));
/* The page next to the pinned page is the first we will try to
get */
start += PAGE_SIZE;
Anyway,
Reviewed-by: Bob Liu
--
Regards,
-Bob
--
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] HID for 3.12-rc2
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus to receive the following: - fixes for CVE-2013-2897, CVE-2013-2895, CVE-2013-2897, CVE-2013-2894, CVE-2013-2893, CVE-2013-2891, CVE-2013-2890, CVE-2013-2889. All the bugs are triggerable only by specially crafted evil-on-purpose HW devices. Fixes by Kees Cook and Benjamin Tissoires. Benjamin Tissoires (3): HID: validate feature and input report details HID: multitouch: validate indexes details HID: lenovo-tpkbd: fix leak if tpkbd_probe_tp fails Kees Cook (7): HID: provide a helper for validating hid reports HID: zeroplus: validate output report details HID: sony: validate HID output report details HID: steelseries: validate output report details HID: LG: validate HID output report details HID: lenovo-tpkbd: validate output report details HID: logitech-dj: validate output report details drivers/hid/hid-core.c | 74 +++- drivers/hid/hid-input.c| 11 +- drivers/hid/hid-lenovo-tpkbd.c | 25 ++--- drivers/hid/hid-lg2ff.c| 19 ++- drivers/hid/hid-lg3ff.c| 29 +++ drivers/hid/hid-lg4ff.c| 20 +-- drivers/hid/hid-lgff.c | 17 + drivers/hid/hid-logitech-dj.c | 10 - drivers/hid/hid-multitouch.c | 26 +++-- drivers/hid/hid-sony.c |4 ++ drivers/hid/hid-steelseries.c |5 +++ drivers/hid/hid-zpff.c | 18 +++--- include/linux/hid.h|4 ++ 13 files changed, 146 insertions(+), 116 deletions(-) -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On 09/17/2013 09:34 PM, Igor Gnatenko wrote: > On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote: >> v1 has the subject of "Rework ACPI video driver" and is posted here: >> http://lkml.org/lkml/2013/9/9/74 >> Since the objective is really to fix Win8 backlight issues, I changed >> the subject in this version, sorry about that. >> >> This patchset has three patches, the first introduced a new API named >> backlight_device_registered in backlight layer that can be used for >> backlight interface provider module to check if a specific type backlight >> interface has been registered, see changelog for patch 1/3 for details. >> Then patch 2/3 does the cleanup to sepeate the backlight control and >> event delivery functionality in the ACPI video module and patch 3/3 >> solves some Win8 backlight control problems by avoiding register ACPI >> video's backlight interface if: >> 1 Kernel cmdline option acpi_backlight=video is not given; >> 2 This is a Win8 system; >> 3 Native backlight control interface exists. >> >> Technically, patch 2/3 is not required to fix the issue here. So if you >> think it is not necessary, I can remove it from the series. >> >> Apply on top of v3.12-rc1. >> >> Aaron Lu (3): >> backlight: introduce backlight_device_registered >> ACPI / video: seperate backlight control and event interface >> ACPI / video: Do not register backlight if win8 and native interface >> exists >> >> drivers/acpi/internal.h | 5 +- >> drivers/acpi/video.c| 442 >> >> drivers/acpi/video_detect.c | 14 +- >> drivers/video/backlight/backlight.c | 31 +++ >> include/acpi/video.h| 2 + >> include/linux/backlight.h | 4 + >> 6 files changed, 300 insertions(+), 198 deletions(-) >> > > Aaron, how about fix indicator on ThinkPads ? Can you please describe the problem in detail, is it that when you adjust brightness level through hotkey, there is no GUI indication? Thanks. -Aaron -- 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-next: manual merge of the vfs tree with the aio-direct tree
Hi Al,
Today's linux-next merge of the vfs tree got conflicts in fs/nfs/direct.c
and fs/nfs/file.c between commits b9517433d65d ("dio: Convert direct_IO
to use iov_iter"), a8431c667ae8 ("nfs: add support for read_iter,
write_iter") and a1b8ec384b73 ("nfs: simplify swap") from the aio-direct
tree and commit c18d1ec44f7a ("nfs: use %p[dD] instead of open-coded (and
often racy) equivalents") from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/nfs/direct.c
index 239c2fe,d71d66c..000
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@@ -118,18 -117,26 +118,17 @@@ static inline int put_dreq(struct nfs_d
* @nr_segs: size of iovec array
*
* The presence of this routine in the address space ops vector means
- * the NFS client supports direct I/O. However, for most direct IO, we
- * shunt off direct read and write requests before the VFS gets them,
- * so this method is only ever called for swap.
+ * the NFS client supports direct I/O. However, we shunt off direct
+ * read and write requests before the VFS gets them, so this method
+ * should never be called.
*/
-ssize_t nfs_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
loff_t pos, unsigned long nr_segs)
+ssize_t nfs_direct_IO(int rw, struct kiocb *iocb, struct iov_iter *iter,
+loff_t pos)
{
- dprintk("NFS: nfs_direct_IO (%s) off/no(%Ld/%lu) EINVAL\n",
- iocb->ki_filp->f_path.dentry->d_name.name,
- (long long) pos, iter->nr_segs);
-#ifndef CONFIG_NFS_SWAP
+ dprintk("NFS: nfs_direct_IO (%pD) off/no(%Ld/%lu) EINVAL\n",
- iocb->ki_filp, (long long) pos, nr_segs);
++ iocb->ki_filp, (long long) pos, iter->nr_segs);
return -EINVAL;
-#else
- VM_BUG_ON(iocb->ki_nbytes != PAGE_SIZE);
-
- if (rw == READ || rw == KERNEL_READ)
- return nfs_file_direct_read(iocb, iov, nr_segs, pos,
- rw == READ ? true : false);
- return nfs_file_direct_write(iocb, iov, nr_segs, pos,
- rw == WRITE ? true : false);
-#endif /* CONFIG_NFS_SWAP */
}
static void nfs_direct_release_pages(struct page **pages, unsigned int npages)
@@@ -1010,13 -905,11 +1009,11 @@@ ssize_t nfs_file_direct_read(struct kio
struct address_space *mapping = file->f_mapping;
size_t count;
- count = iov_length(iov, nr_segs);
+ count = iov_iter_count(iter);
nfs_add_stats(mapping->host, NFSIOS_DIRECTREADBYTES, count);
- dfprintk(FILE, "NFS: direct read(%s/%s, %zd@%Ld)\n",
- file->f_path.dentry->d_parent->d_name.name,
- file->f_path.dentry->d_name.name,
- count, (long long) pos);
+ dfprintk(FILE, "NFS: direct read(%pD2, %zd@%Ld)\n",
+ file, count, (long long) pos);
retval = 0;
if (!count)
@@@ -1065,13 -959,11 +1062,11 @@@ ssize_t nfs_file_direct_write(struct ki
struct address_space *mapping = file->f_mapping;
size_t count;
- count = iov_length(iov, nr_segs);
+ count = iov_iter_count(iter);
nfs_add_stats(mapping->host, NFSIOS_DIRECTWRITTENBYTES, count);
- dfprintk(FILE, "NFS: direct write(%s/%s, %zd@%Ld)\n",
- file->f_path.dentry->d_parent->d_name.name,
- file->f_path.dentry->d_name.name,
- count, (long long) pos);
+ dfprintk(FILE, "NFS: direct write(%pD2, %zd@%Ld)\n",
+ file, count, (long long) pos);
retval = generic_write_checks(file, , , 0);
if (retval)
diff --cc fs/nfs/file.c
index 19ac4fd,e2fcacf..000
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@@ -174,18 -165,18 +165,17 @@@ nfs_file_flush(struct file *file, fl_ow
EXPORT_SYMBOL_GPL(nfs_file_flush);
ssize_t
-nfs_file_read(struct kiocb *iocb, const struct iovec *iov,
- unsigned long nr_segs, loff_t pos)
+nfs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter, loff_t pos)
{
- struct dentry * dentry = iocb->ki_filp->f_path.dentry;
- struct inode * inode = dentry->d_inode;
+ struct inode *inode = file_inode(iocb->ki_filp);
ssize_t result;
if (iocb->ki_filp->f_flags & O_DIRECT)
- return nfs_file_direct_read(iocb, iov, nr_segs, pos, true);
+ return nfs_file_direct_read(iocb, iter, pos);
- dprintk("NFS: read_iter(%s/%s, %lu@%lu)\n",
- dentry->d_parent->d_name.name, dentry->d_name.name,
- dprintk("NFS: read(%pD2, %lu@%lu)\n",
++ dprintk("NFS: read_iter(%pD2, %lu@%lu)\n",
+ iocb->ki_filp,
- (unsigned long) iov_length(iov, nr_segs), (unsigned long) pos);
+ (unsigned long) iov_iter_count(iter), (unsigned long) pos);
result =
Re: [PATCH PING] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
[Resending without HTML part - sorry for possible duplicates]
As requested by Peter, resending the patch with ACPI/x86 maintainers CC'ed.
Short description:
Make coalesce_windows() handle multiple resource overlaps.
Signed-off-by: Alexey Neyman
Regards,
Alexey.
On Monday, September 16, 2013 07:31:58 PM Peter Hurley wrote:
> [ +cc Bjorn Helgaas, Rafael Wysocki, linux-acpi ]
>
> On 09/16/2013 12:41 PM, Alexey Neyman wrote:
> > Hi all,
> >
> > Could anybody review/commit the patch?
>
> LKML is a pretty general list and maintainers don't typically
> trawl the list for more work to do. The get_maintainer script
> can be used to help determine to whom to address a patch.
>
> peter@thor:~/src/kernels/next$ ./scripts/get_maintainer.pl -f
> arch/x86/pci/acpi.c Thomas Gleixner (maintainer:X86
> ARCHITECTURE...) Ingo Molnar (maintainer:X86
> ARCHITECTURE...)
> "H. Peter Anvin" (maintainer:X86 ARCHITECTURE...)
> x...@kernel.org (maintainer:X86 ARCHITECTURE...)
> Bjorn Helgaas (commit_signer:5/8=62%)
> "Rafael J. Wysocki" (commit_signer:3/8=38%)
> Feng Tang (commit_signer:1/8=12%)
> Yijing Wang (commit_signer:1/8=12%)
> Mike Yoknis (commit_signer:1/8=12%)
> linux-kernel@vger.kernel.org (open list)
>
> Regards,
> Peter Hurley
>
> PS - You'll want to inline your patch as well because as you can see
> replies don't include it.
>
> > Regards,
> > Alexey.
> >
> > On Thursday, September 12, 2013 05:19:16 pm Alexey Neyman wrote:
> >> Hi all,
> >>
> >> I have a board with a BIOS bug that reports the following I/O port
> >> regions
> >> in _CRS on one of the host bridges:
> >>
> >> 0x-0x03af // #0
> >> 0x03e0-0x0cf7 // #1
> >> 0x03b0-0x03bb // #2
> >> 0x03c0-0x03df // #3
> >> 0x-0xdfff // #4
> >> 0xf000-0x // #5
> >>
> >> Obviously, region number #4 is erroneous as it overlaps with regions
> >> #0..3.
> >> However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to
> >> recover from such kind of BIOS bugs by merging the overlapping regions.
> >> Current code expands region #0 to 0x-0xd and makes region #4
> >> ignored. As a result, overlap of the expanded region #0 with regions
> >> #1..3
> >> remains undetected. As a result, regions #1..3 are inserted into the
> >> resource tree as if they were consumers of the 0x-0xdfff regions, and
> >> devices that have resources in one of these regions (e.g. 0x3f6 for
> >> legacy
> >> IDE) have a resource conflict - the kernel does not initialize them.
> >>
> >> The attached patch makes the code in coalesce_windows() instead ignore
> >> res1
> >> (which is already dealt with), possibly expanding res2 instead. As res2
> >> has
> >> not been reached in the outer loop in coalesce_windows(), the code will
> >> then check for overlaps of the just-expanded resource with the rest of
> >> the
> >> resources.
> >>
> >> Regards,
> >> Alexey.--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
Re: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
On 09/12/2013 09:09 PM, Fengguang Wu wrote: On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote: Hi Peter, FYI, we noticed much increased vmap_area_lock contentions since this commit: commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77 Author: Peter Hurley Date: Sat Jun 15 10:21:19 2013 -0400 n_tty: Move buffers into n_tty_data Reduce pointer reloading and improve locality-of-reference; allocate read_buf and echo_buf within struct n_tty_data. Here are some comparison between this commit [o] with its parent commit [*]. [...] 8cb06c983822103da1cf 20bafb3d23d108bc0a89 976.67 +108.3% 2034.67 lkp-a04/micro/netperf/120s-200%-TCP_STREAM 8971.36 +11.4% 9997.05 nhm-white/micro/aim7/exec_test 9948.03 +20.9% 12031.72 TOTAL slabinfo.kmalloc-128.active_objs 8cb06c983822103da1cf 20bafb3d23d108bc0a89 976.67 +108.3% 2034.67 lkp-a04/micro/netperf/120s-200%-TCP_STREAM 9127.64 +11.4% 10164.15 nhm-white/micro/aim7/exec_test 10104.31 +20.7% 12198.82 TOTAL slabinfo.kmalloc-128.num_objs The dramatic increase in 128-byte kmalloc blocks is from vmalloc overhead with associated with each allocation. On a x86_64, struct vmap_area is 104 bytes, rounded to 128, allocated with every vmalloc allocation. This is approx 1% overhead (which seems high to me). The reason this is still visible after the test completes is the vmap area is lazily reclaimed (see mm/vmalloc.c:__purge_vmap_area_lazy()). 1% memory overhead coupled with the unwanted vmap_area_lock contention (even though it is test-induced) -- I might revert this anyway. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] mm/hwpoison: fix miss catch transparent huge page
Changelog:
*v1 -> v2: reverse PageTransHuge(page) && !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Reviewed-by: Naoya Horiguchi
Acked-by: Andi Kleen
Signed-off-by: Wanpeng Li
---
mm/memory-failure.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..ed41c63 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) && PageTransHuge(page)) {
pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
return 0;
}
--
1.7.5.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 v3 1/4] mm/hwpoison: fix traverse hugetlbfs page to avoid printk flood
madvise_hwpoison won't check if the page is small page or huge page and traverse
in small page granularity against the range unconditional, which result in a
printk
flood "MCE xxx: already hardware poisoned" if the page is huge page. This patch
fix
it by increase compound_order(compound_head(page)) for huge page iterator.
Testcase:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#define PAGES_TO_TEST 3
#define PAGE_SIZE 4096 * 512
int main(void)
{
char *mem;
int i;
mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS |
MAP_HUGETLB, 0, 0);
if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;
munmap(mem, PAGES_TO_TEST * PAGE_SIZE);
return 0;
}
Reviewed-by: Naoya Horiguchi
Acked-by: Andi Kleen
Signed-off-by: Wanpeng Li
---
mm/madvise.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6975bc8..539eeb9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -343,10 +343,11 @@ static long madvise_remove(struct vm_area_struct *vma,
*/
static int madvise_hwpoison(int bhv, unsigned long start, unsigned long end)
{
+ struct page *p;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- for (; start < end; start += PAGE_SIZE) {
- struct page *p;
+ for (; start < end; start += PAGE_SIZE <<
+ compound_order(compound_head(p))) {
int ret;
ret = get_user_pages_fast(start, 1, 0, );
--
1.7.5.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 v3 3/4] mm/hwpoison: fix false report 2nd try page recovery
If the page is poisoned by software inject w/ MF_COUNT_INCREASED flag, there
is a false report 2nd try page recovery which is not truth, this patch fix it
by report first try free buddy page recovery if MF_COUNT_INCREASED is set.
Before patch:
[ 346.332041] Injecting memory failure at pfn 200010
[ 346.332189] MCE 0x200010: free buddy, 2nd try page recovery: Delayed
After patch:
[ 297.742600] Injecting memory failure at pfn 200010
[ 297.742941] MCE 0x200010: free buddy page recovery: Delayed
Reviewed-by: Naoya Horiguchi
Acked-by: Andi Kleen
Signed-off-by: Wanpeng Li
---
mm/memory-failure.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index ed41c63..615764c 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1114,8 +1114,10 @@ int memory_failure(unsigned long pfn, int trapno, int
flags)
* shake_page could have turned it free.
*/
if (is_free_buddy_page(p)) {
- action_result(pfn, "free buddy, 2nd try",
- DELAYED);
+ if (flags & MF_COUNT_INCREASED)
+ action_result(pfn, "free buddy",
DELAYED);
+ else
+ action_result(pfn, "free buddy, 2nd
try", DELAYED);
return 0;
}
action_result(pfn, "non LRU", IGNORED);
--
1.7.5.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 v3 4/4] mm/hwpoison: fix the lack of one reference count against poisoned page
The lack of one reference count against poisoned page for hwpoison_inject w/o hwpoison_filter enabled result in hwpoison detect -1 users still referenced the page, however, the number should be 0 except the poison handler held one after successfully unmap. This patch fix it by hold one referenced count against poisoned page for hwpoison_inject w/ and w/o hwpoison_filter enabled. Before patch: [ 71.902112] Injecting memory failure at pfn 224706 [ 71.902137] MCE 0x224706: dirty LRU page recovery: Failed [ 71.902138] MCE 0x224706: dirty LRU page still referenced by -1 users After patch: [ 94.710860] Injecting memory failure at pfn 215b68 [ 94.710885] MCE 0x215b68: dirty LRU page recovery: Recovered Reviewed-by: Naoya Horiguchi Acked-by: Andi Kleen Signed-off-by: Wanpeng Li --- mm/hwpoison-inject.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c index afc2daa..4c84678 100644 --- a/mm/hwpoison-inject.c +++ b/mm/hwpoison-inject.c @@ -20,8 +20,6 @@ static int hwpoison_inject(void *data, u64 val) if (!capable(CAP_SYS_ADMIN)) return -EPERM; - if (!hwpoison_filter_enable) - goto inject; if (!pfn_valid(pfn)) return -ENXIO; @@ -33,6 +31,9 @@ static int hwpoison_inject(void *data, u64 val) if (!get_page_unless_zero(hpage)) return 0; + if (!hwpoison_filter_enable) + goto inject; + if (!PageLRU(p) && !PageHuge(p)) shake_page(p, 0); /* -- 1.7.5.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: linux-next stats (Was: Linux 3.12-rc1)
Hi Nicholas, On Tue, 17 Sep 2013 17:23:41 -0700 "Nicholas A. Bellinger" wrote: > > On Tue, 2013-09-17 at 15:50 +1000, Stephen Rothwell wrote: > > On Mon, 16 Sep 2013 18:08:11 -0400 Linus Torvalds > > wrote: > > > > > > So it's been two weeks, and the merge window for 3.12 is now closed. > > > > As usual, the executive friendly graph is at > > http://neuling.org/linux-next-size.html :-) > > > > (No merge commits counted, next-20130903 was the linux-next based on v3.11) > > > > Commits in v3.12-rc1 (relative to v3.11): 9474 (v3.11-rc11: > > 9494) > > Commits in next-20130903: 8891 (next-20130701: 8929) > > Commits with the same SHA1: 7991 ( 7670) > > Commits with the same patch_id:472 (1) ( > > 759) > > Commits with the same subject line: 70 (1) ( 55) > > > > (1) not counting those in the lines above. > > > > So commits in -rc1 that were "in" next-20130903:853390.1% (8484 > > 89.4%) > > Commits in -rc1 that were not in next-20120722: 941 9.9% > > (1010 10.6% > > > > So better than last time, but it would be still nice to figure out where > > the last lot came from. I have the "git log --oneline --no-walk" list if > > someone wants them. > > > > Some breakdown of that list: > > > > Top ten first word of commit summary: > > > > 57 net > > 53 mips > > 49 drm > > 47 [scsi] > > 23 perf > > 23 nfs > > 20 cifs > > 19 nvme > > 18 vfs > > 17 arm > > > > Top ten authors: > > > > 33 Al Viro > > 21 Sachin Kamat > > 20 Linus Torvalds > > 18 James Smart > > 17 Jon Mason > > 17 Chuck Lever > > 16 Tomasz Figa > > 16 Jingoo Han > > 15 Daniel Borkmann > > 14 Trond Myklebust > > I'm totally confused by these stats.. > > The target-pending/for-next pull had ~30 commits with the term 'target' > in the first word of the commit summary, and yours truly had 40 commits > merged. > > Is there a reason why these would not be showing up in the above..? These are the lists if things that went into Linus' tree but were *not* in linux-next prior to the merge window opening. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpI2UawKHN7W.pgp Description: PGP signature
Help. INFO: possible circular locking dependency detected
During suspend-to-RAM, I see an info message below. Could anybody
advice how to debug this problem or anyone has experienced this
before? (ARM mach)
Thanks a lot for any help.
[ 172.637547] ==
[ 172.637555] [ INFO: possible circular locking dependency detected ]
[ 172.637565] 3.10.5+ #1 Not tainted
[ 172.637573] ---
[ 172.637581] kworker/u12:0/6 is trying to acquire lock:
[ 172.637628] (cpu_add_remove_lock){+.+.+.}, at: []
cpu_maps_update_begin+0x20/0x28
[ 172.637635]
[ 172.637635] but task is already holding lock:
[ 172.637671] (console_lock){+.+.+.}, at: []
suspend_console+0x30/0x54
[ 172.637679]
[ 172.637679] which lock already depends on the new lock.
[ 172.637679]
[ 172.637686]
[ 172.637686] the existing dependency chain (in reverse order) is:
[ 172.637714]
[ 172.637714] -> #2 (console_lock){+.+.+.}:
[ 172.637734][] check_prevs_add+0x704/0x874
[ 172.637752][] validate_chain.isra.24+0x5e0/0x9b0
[ 172.637769][] __lock_acquire+0x3fc/0xbcc
[ 172.637786][] lock_acquire+0xa4/0x208
[ 172.637804][] console_lock+0x70/0x88
[ 172.637824][] console_cpu_notify+0x28/0x34
[ 172.637844][] notifier_call_chain+0x74/0x138
[ 172.637864][] __raw_notifier_call_chain+0x24/0x2c
[ 172.637880][] __cpu_notify+0x38/0x54
[ 172.637896][] cpu_notify+0x20/0x24
[ 172.637913][] cpu_notify_nofail+0x18/0x24
[ 172.637929][] _cpu_down+0x108/0x2b8
[ 172.637946][] cpu_down+0x34/0x50
[ 172.637962][] store_online+0x40/0x84
[ 172.637981][] dev_attr_store+0x28/0x34
[ 172.638000][] sysfs_write_file+0x17c/0x1ac
[ 172.638018][] vfs_write+0xc0/0x19c
[ 172.638034][] SyS_write+0x4c/0x80
[ 172.638053][] ret_fast_syscall+0x0/0x48
[ 172.638081]
[ 172.638081] -> #1 (cpu_hotplug.lock){+.+.+.}:
[ 172.638098][] check_prevs_add+0x704/0x874
[ 172.638116][] validate_chain.isra.24+0x5e0/0x9b0
[ 172.638132][] __lock_acquire+0x3fc/0xbcc
[ 172.638149][] lock_acquire+0xa4/0x208
[ 172.638166][] mutex_lock_nested+0x74/0x3f8
[ 172.638183][] cpu_hotplug_begin+0x3c/0x68
[ 172.638200][] _cpu_up+0x2c/0x15c
[ 172.638216][] cpu_up+0x6c/0x8c
[ 172.638236][] smp_init+0x9c/0xd4
[ 172.638254][] kernel_init_freeable+0x78/0x1cc
[ 172.638270][] kernel_init+0x18/0xf4
[ 172.638288][] ret_from_fork+0x14/0x20
[ 172.638316]
[ 172.638316] -> #0 (cpu_add_remove_lock){+.+.+.}:
[ 172.638335][] print_circular_bug+0x70/0x2e4
[ 172.638352][] check_prevs_add+0x844/0x874
[ 172.638370][] validate_chain.isra.24+0x5e0/0x9b0
[ 172.638387][] __lock_acquire+0x3fc/0xbcc
[ 172.638404][] lock_acquire+0xa4/0x208
[ 172.638421][] mutex_lock_nested+0x74/0x3f8
[ 172.638438][] cpu_maps_update_begin+0x20/0x28
[ 172.638455][] disable_nonboot_cpus+0x20/0xf4
[ 172.638476][] suspend_devices_and_enter+0x1b0/0x574
[ 172.638494][] pm_suspend+0x1d0/0x288
[ 172.638512][] try_to_suspend+0xc0/0xdc
[ 172.638530][] process_one_work+0x1c8/0x684
[ 172.638547][] worker_thread+0x144/0x394
[ 172.638565][] kthread+0xb4/0xc0
[ 172.638582][] ret_from_fork+0x14/0x20
[ 172.638590]
[ 172.638590] other info that might help us debug this:
[ 172.638590]
[ 172.638630] Chain exists of:
[ 172.638630] cpu_add_remove_lock --> cpu_hotplug.lock --> console_lock
[ 172.638630]
[ 172.638637] Possible unsafe locking scenario:
[ 172.638637]
[ 172.638644]CPU0CPU1
[ 172.638651]
[ 172.638668] lock(console_lock);
[ 172.638685]lock(cpu_hotplug.lock);
[ 172.638703]lock(console_lock);
[ 172.638720] lock(cpu_add_remove_lock);
[ 172.638726]
[ 172.638726] *** DEADLOCK ***
[ 172.638726]
[ 172.638735] 5 locks held by kworker/u12:0/6:
[ 172.638774] #0: (autosleep){.+.+.+}, at: []
process_one_work+0x138/0x684
[ 172.638813] #1: (suspend_work){+.+.+.}, at: []
process_one_work+0x138/0x684
[ 172.638853] #2: (autosleep_lock){+.+.+.}, at: []
try_to_suspend+0x38/0xdc
[ 172.638893] #3: (pm_mutex){+.+.+.}, at: [] pm_suspend+0x44/0x288
[ 172.638933] #4: (console_lock){+.+.+.}, at: []
suspend_console+0x30/0x54
[ 172.638939]
[ 172.638939] stack backtrace:
[ 172.638952] CPU: 0 PID: 6 Comm: kworker/u12:0 Not tainted 3.10.5+ #1
[ 172.638973] Workqueue: autosleep try_to_suspend
[ 172.638997] [] (unwind_backtrace+0x0/0x144) from
[] (show_stack+0x20/0x24)
[ 172.639017] [] (show_stack+0x20/0x24) from []
(dump_stack+0x20/0x28)
[ 172.639038] [] (dump_stack+0x20/0x28) from []
(print_circular_bug+0x290/0x2e4)
[ 172.639057] [] (print_circular_bug+0x290/0x2e4) from
[]
[PATCH v6 1/2] mm/vmalloc: fix show vmap_area information race with vmap_area tear down
Changelog:
*v4 -> v5: return directly for !VM_VM_AREA case and remove (VM_LAZY_FREE |
VM_LAZY_FREEING) check
*v5 -> v6: add KOSAKI's ack
There is a race window between vmap_area tear down and show vmap_area
information.
AB
remove_vm_area
spin_lock(_area_lock);
va->vm = NULL;
va->flags &= ~VM_VM_AREA;
spin_unlock(_area_lock);
spin_lock(_area_lock);
if (va->flags & (VM_LAZY_FREE |
VM_LAZY_FREEZING))
return 0;
if (!(va->flags & VM_VM_AREA)) {
seq_printf(m,
"0x%pK-0x%pK %7ld vm_map_ram\n",
(void
*)va->va_start, (void *)va->va_end,
va->va_end -
va->va_start);
return 0;
}
free_unmap_vmap_area(va);
flush_cache_vunmap
free_unmap_vmap_area_noflush
unmap_vmap_area
free_vmap_area_noflush
va->flags |= VM_LAZY_FREE
The assumption !VM_VM_AREA represents vm_map_ram allocation is introduced by
commit: d4033afd(mm, vmalloc: iterate vmap_area_list, instead of vmlist, in
vmallocinfo()). However, !VM_VM_AREA also represents vmap_area is being tear
down in race window mentioned above. This patch fix it by don't dump any
information for !VM_VM_AREA case and also remove (VM_LAZY_FREE |
VM_LAZY_FREEING)
check since they are not possible for !VM_VM_AREA case.
Suggested-by: Joonsoo Kim
Acked-by: KOSAKI Motohiro
Signed-off-by: Wanpeng Li
---
mm/vmalloc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5368b17..9b75028 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2582,16 +2582,13 @@ static int s_show(struct seq_file *m, void *p)
{
struct vmap_area *va = p;
struct vm_struct *v;
-
- if (va->flags & (VM_LAZY_FREE | VM_LAZY_FREEING))
- return 0;
-
- if (!(va->flags & VM_VM_AREA)) {
- seq_printf(m, "0x%pK-0x%pK %7ld vm_map_ram\n",
- (void *)va->va_start, (void *)va->va_end,
- va->va_end - va->va_start);
+
+ /*
+* s_show can encounter race with remove_vm_area, !VM_VM_AREA on
+* behalf of vmap area is being tear down or vm_map_ram allocation.
+*/
+ if (!(va->flags & VM_VM_AREA))
return 0;
- }
v = va->vm;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/2] mm/vmalloc: drop "caller" argument of __vmalloc_area_node()
__vmalloc_area_node() no longer need "caller" argument. It can use area->caller
instead. This patch drop "caller" argument of __vmalloc_area_node().
Signed-off-by: Wanpeng Li
---
mm/vmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d78d117..f75c2aa 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1546,7 +1546,7 @@ static void *__vmalloc_node(unsigned long size, unsigned
long align,
gfp_t gfp_mask, pgprot_t prot,
int node, const void *caller);
static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
-pgprot_t prot, int node, const void *caller)
+pgprot_t prot, int node)
{
const int order = 0;
struct page **pages;
@@ -1560,7 +1560,7 @@ static void *__vmalloc_area_node(struct vm_struct *area,
gfp_t gfp_mask,
/* Please note that the recursion is strictly bounded. */
if (array_size > PAGE_SIZE) {
pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
- PAGE_KERNEL, node, caller);
+ PAGE_KERNEL, node, area->caller);
area->flags |= VM_VPAGES;
} else {
pages = kmalloc_node(array_size, nested_gfp, node);
@@ -1633,7 +1633,7 @@ void *__vmalloc_node_range(unsigned long size, unsigned
long align,
if (!area)
goto fail;
- addr = __vmalloc_area_node(area, gfp_mask, prot, node, caller);
+ addr = __vmalloc_area_node(area, gfp_mask, prot, node);
if (!addr)
goto fail;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Vážení E-mail užívateľa;
Vážení E-mail užívateľa; Prekročili ste 23432 boxy nastaviť svoje Webová služba / Administrátor, a budete mať problémy pri odosielaní a prijímať e-maily, kým znova overiť. Musíte aktualizovať kliknutím na odkaz nižšie a vyplňte údaje pre overenie vášho účtu Prosím, kliknite na odkaz nižšie alebo skopírovať vložiť do e-prehliadač pre overenie Schránky. http://webmailupdateonlin121er.jimdo.com/ Pozor! Ak tak neurobíte, budú mať obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovať svoj účet do troch dní od aktualizácie oznámenia, bude váš účet natrvalo uzavretá. S pozdravom, System Administrator -- 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: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
On 09/17/2013 07:22 PM, Fengguang Wu wrote: On Tue, Sep 17, 2013 at 11:34:21AM -0400, Peter Hurley wrote: On 09/12/2013 09:09 PM, Fengguang Wu wrote: On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote: Hi Peter, FYI, we noticed much increased vmap_area_lock contentions since this commit: commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77 Author: Peter Hurley Date: Sat Jun 15 10:21:19 2013 -0400 n_tty: Move buffers into n_tty_data Reduce pointer reloading and improve locality-of-reference; allocate read_buf and echo_buf within struct n_tty_data. Here are some comparison between this commit [o] with its parent commit [*]. Hi Fengguang, Sorry for misspelling your name earlier. Fixed. Can you give the particulars of the aim7 test runs below? I ask because I get _no_ added contention on the vmap_area_lock when I run these tests on a dual-socket xeon. What is the machine configuration(s)? Are you using the aim7 'multitask' test driver or your own custom driver? What is the load configuration (ie., constant, linearly increasing, convergence)? How many loads are you simulating? The aim7 tests are basically ( echo $HOSTNAME echo $workfile echo 1 echo 2000 echo 2 echo 2000 echo 1 ) | ./multitask -t Thanks for the profile. I ran the aim7 tests with these load parameters (2000!) and didn't have any significant contention with vmap_area_lock (162). I had to run a subset of the aim7 tests (just those below) because I don't have anything fast enough to simulate 2000 loads on the entire workfile.shared testsuite. lock_stat.vmap_area_lock.holdtime-total [...] 489739.50 +978.5% 5281916.05 lkp-ne04/micro/aim7/shell_rtns_1 1601675.63 +906.7% 16123642.52 lkp-snb01/micro/aim7/exec_test [...] 822461.02 +1585.0% 13858430.62 nhm-white/micro/aim7/exec_test 9858.11 +2715.9%277595.41 nhm-white/micro/aim7/fork_test [...] 300.14 +2621.5% 8168.53 nhm-white/micro/aim7/misc_rtns_1 345479.21 +1624.5% 5957828.25 nhm-white/micro/aim7/shell_rtns_1 None of the tests below execute a code path that leads to get_vmalloc_info(). The only in-kernel user of get_vmalloc_info() is a sysfs read of /proc/meminfo, which none of the tests below perform. What is reading /proc/meminfo? Good point! That may explain it: I'm running a loop: cat /proc/meminfo sleep 1 in all the tests. Yep. That's what's creating the contention -- while the aim7 test is creating ttys for each and every process (exec_test, shell_rtns_1, ...), the read of /proc/meminfo is contending with the allocations/frees of 2000 tty ldisc buffers. Looking over vmalloc.c, the critical section footprint of the vmap_area_lock could definitely be reduced (even nearly eliminated), but that's a project for another day :) Regards, Peter Hurley lock_stat.vmap_area_lock.contentions.get_vmalloc_info 8cb06c983822103da1cf 20bafb3d23d108bc0a89 4952.40 +447.0% 27090.40 lkp-ne04/micro/aim7/shell_rtns_1 28410.80 +556.2%186423.00 lkp-snb01/micro/aim7/exec_test 8142.00 +615.4% 58247.33 nhm-white/micro/aim7/exec_test 1386.00 +762.6% 11955.20 nhm-white/micro/aim7/shell_rtns_1 42891.20 +561.5%283715.93 TOTAL lock_stat.vmap_area_lock.contentions.get_vmalloc_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/
Re: linux-next stats (Was: Linux 3.12-rc1)
Hi Stephen, On Tue, 2013-09-17 at 15:50 +1000, Stephen Rothwell wrote: > On Mon, 16 Sep 2013 18:08:11 -0400 Linus Torvalds > wrote: > > > > So it's been two weeks, and the merge window for 3.12 is now closed. > > As usual, the executive friendly graph is at > http://neuling.org/linux-next-size.html :-) > > (No merge commits counted, next-20130903 was the linux-next based on v3.11) > > Commits in v3.12-rc1 (relative to v3.11): 9474(v3.11-rc11: > 9494) > Commits in next-20130903: 8891 (next-20130701: 8929) > Commits with the same SHA1: 7991 ( 7670) > Commits with the same patch_id: 472 (1) ( > 759) > Commits with the same subject line: 70 (1) ( 55) > > (1) not counting those in the lines above. > > So commits in -rc1 that were "in" next-20130903: 853390.1% (8484 > 89.4%) > Commits in -rc1 that were not in next-20120722:941 9.9% > (1010 10.6% > > So better than last time, but it would be still nice to figure out where > the last lot came from. I have the "git log --oneline --no-walk" list if > someone wants them. > > Some breakdown of that list: > > Top ten first word of commit summary: > > 57 net > 53 mips > 49 drm > 47 [scsi] > 23 perf > 23 nfs > 20 cifs > 19 nvme > 18 vfs > 17 arm > > Top ten authors: > > 33 Al Viro > 21 Sachin Kamat > 20 Linus Torvalds > 18 James Smart > 17 Jon Mason > 17 Chuck Lever > 16 Tomasz Figa > 16 Jingoo Han > 15 Daniel Borkmann > 14 Trond Myklebust > I'm totally confused by these stats.. The target-pending/for-next pull had ~30 commits with the term 'target' in the first word of the commit summary, and yours truly had 40 commits merged. Is there a reason why these would not be showing up in the above..? --nab -- 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 5/6] sparc: Use preempt_schedule_irq
From: Thomas Gleixner Date: Wed, 18 Sep 2013 01:23:58 +0200 (CEST) > I knew that I'd get it wrong :) So is adding another nop the right > thing to do ? > > bne,pn %xcc, kern_fpucheck > - sethi %hi(PREEMPT_ACTIVE), %l6 > - stw %l6, [%g6 + TI_PRE_COUNT] > - callschedule > + nop > + callpreempt_schedule_irq >nop Yep, that's perfect: Acked-by: David S. Miller -- 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] scsi: delete decade+ obsolete aic7xxx_old driver
[Re: [PATCH] scsi: delete decade+ obsolete aic7xxx_old driver] On 17/09/2013 (Tue 16:27) Doug Ledford wrote: > On 09/17/13 16:10, James Bottomley wrote: > > > OK, so do we have any real evidence that no-one uses this driver? Does > > any distro actually compile it, for instance? > > Red Hat doesn't use it in any of their products (and it hasn't been the > preferred driver since about the old Red Hat Linux 7.0 days). The oldest ubuntu machine I could find was running a 2.6.32 kernel and even back then, they weren't building/enabling this driver either. Paul. -- > > > -- > Doug Ledford > GPG KeyID: 0E572FDD > http://people.redhat.com/dledford > -- 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] drm/msm: Odd PTR_ERR usage
On Mon, Sep 16, 2013 at 5:19 PM, Thomas Meyer wrote: > The variable priv->kms is not initialized yet. > > Found by "scripts/coccinelle/tests/odd_ptr_err.cocci". > PTR_ERR should access the value just tested by IS_ERR. > > Signed-off-by: Thomas Meyer thanks, I've got it queued up BR, -R > --- > > diff -u -p a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -199,7 +199,7 @@ static int msm_load(struct drm_device *d > * imx drm driver on iMX5 > */ > dev_err(dev->dev, "failed to load kms\n"); > - ret = PTR_ERR(priv->kms); > + ret = PTR_ERR(kms); > 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: bcm: Add DEBUG_LL console support
This patch adds low level debug uart support to Broadcom mobile based SOCs. Signed-off-by: Christian Daudt Changes from V1: - Switched to use the common 8250 debug introduced in 3.12-rc1 diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 9762c84..0523e71 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -94,6 +94,17 @@ choice depends on ARCH_BCM2835 select DEBUG_UART_PL01X + config DEBUG_BCM_KONA_UART + bool "Kernel low-level debugging messages via BCM KONA UART" + depends on ARCH_BCM + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on Broadcom SoC platforms. + This low level debug works for Broadcom + mobile SoCs in the Kona family of chips (e.g. bcm28155, + bcm11351, etc...) + config DEBUG_CLPS711X_UART1 bool "Kernel low-level debugging messages via UART1" depends on ARCH_CLPS711X @@ -980,6 +991,7 @@ config DEBUG_UART_PHYS default 0xffd82340 if ARCH_IOP13XX default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X + default 0x3e00 if DEBUG_BCM_KONA_UART depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ DEBUG_UART_8250 || DEBUG_UART_PL01X @@ -1035,6 +1047,7 @@ config DEBUG_UART_VIRT default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN default 0xfefff700 if ARCH_IOP33X default 0xff003000 if DEBUG_U300_UART + default 0xfe30 if DEBUG_BCM_KONA_UART default DEBUG_UART_PHYS if !MMU depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ DEBUG_UART_8250 || DEBUG_UART_PL01X @@ -1052,7 +1065,8 @@ config DEBUG_UART_8250_WORD default y if DEBUG_PICOXCELL_UART || DEBUG_SOCFPGA_UART || \ ARCH_KEYSTONE || \ DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \ - DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1 + DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1 || \ + DEBUG_BCM_KONA_UART config DEBUG_UART_8250_FLOW_CONTROL bool "Enable flow control for 8250 UART" diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig index 6e49310..5c12c4c 100644 --- a/arch/arm/configs/bcm_defconfig +++ b/arch/arm/configs/bcm_defconfig @@ -30,6 +30,8 @@ CONFIG_ARCH_BCM=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_743622=y CONFIG_PREEMPT=y +CONFIG_DEBUG_LL=y +CONFIG_DEBUG_BCM_KONA_UART=y CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set # CONFIG_COMPACTION is not set -- 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 v2] ADP1653 board code for Nokia RX-51
* Aaro Koskinen [130907 16:10]: > Hi, > > On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote: > > > --- /dev/null > > > +++ b/arch/arm/mach-omap2/board-rx51-camera.c > [...] > > Ping, can you review this patch v2? > > I don't think Tony will accept any new board stuff for RX-51/N900. > See for example: http://marc.info/?l=linux-kernel=137629626213187=2 > > There should be initial Nokia N900 DTS file in 3.12-rc1, and we should > continue converting this board fully to DT. Yes let's plan on making mach-omap2 to be DT only soonish. AFAIK the only stopper right now for omap3 are the pending pinctrl changes for the wake-up events as otherwise we would have sever PM regressions with off-idle. Regards, Tony -- 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] mailbox: remove unnecessary platform_set_drvdata()
* Suman Anna [130823 09:50]: > + OMAP mailing list > > Tony, > Can you pick up this minor cleanup patch? > > regards > Suman > > On 08/21/2013 09:10 PM, Jingoo Han wrote: > > The driver core clears the driver data to NULL after device_release > > or on probe failure. Thus, it is not needed to manually clear the > > device driver data to NULL. > > > > Signed-off-by: Jingoo Han > > Acked-by: Suman Anna OK applying into omap-for-v3.12/fixes thanks. Regards, Tony > > --- > > drivers/mailbox/mailbox-omap2.c |1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/mailbox/mailbox-omap2.c > > b/drivers/mailbox/mailbox-omap2.c > > index eba380d..42d2b89 100644 > > --- a/drivers/mailbox/mailbox-omap2.c > > +++ b/drivers/mailbox/mailbox-omap2.c > > @@ -325,7 +325,6 @@ static int omap2_mbox_remove(struct platform_device > > *pdev) > > kfree(privblk); > > kfree(mboxblk); > > kfree(list); > > - platform_set_drvdata(pdev, NULL); > > > > return 0; > > } > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM: OMAP2: Make MACH_OMAP3EVM select NOP_USB_XCEIV
* Josh Boyer [130904 06:46]: > The board-omap3evm.c file unconditionally calls usb_nop_xceiv_register but > doesn't ensure this is built-in. This can lead to build failures like: > > arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init': > linux-3.12.0-0.rc0.git2.1.fc21.armv7hl/arch/arm/mach-omap2/board-omap3evm.c:686: > undefined reference to `usb_nop_xceiv_register' > make: *** [vmlinux] Error 1 > > Make MACH_OMAP3EVM select NOP_USB_XCEIV to avoid this. > > Signed-off-by: Josh Boyer > --- > arch/arm/mach-omap2/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 3eed000..3350389 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -258,6 +258,7 @@ config MACH_OMAP3EVM > depends on ARCH_OMAP3 > default y > select OMAP_PACKAGE_CBB > + select NOP_USB_XCEIV > > config MACH_OMAP3517EVM > bool "OMAP3517/ AM3517 EVM board" I think we should rather have the code in board-omap3evm.c to be ifdef CONFIG_NOP_USB_XCEIV as it's a selectable option. Regards, Tony -- 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] regulator: fix fatal kernel-doc error
On Tue, Sep 17, 2013 at 08:23:55PM +0100, Mark Brown wrote: > On Tue, Sep 17, 2013 at 10:09:24AM -0700, Randy Dunlap wrote: > > On 09/17/13 03:32, Mark Brown wrote: > > /** means kernel-doc syntax and it was not in proper kernel-doc format, > > but maybe it could just be a Warning instead of a fatal Error. > > Yes, that's what I'm saying - it really doesn't seem like something that > should be a fatal error, that's far too fragile. > > > Ideally we should pick it up in -next, of course, but I doubt that anyone > > is running kernel-doc on linux-next. I used to do that, but there are > > too many errors/warnings. I suppose that I could just concentrate on > > (fatal) Errors in linux-next and ignore the Warnings. > > Could these checks be added to Fengguang's tester? If nobody's looking > at the output (I've never found the processed output useful myself) or > running the tool then it's a bit worrying... Yes, I'm running "make htmldocs" checks and send out all new warnings: Sep 03 To Mark Brown ( 19:0) [regulator:topic/devm 5/15] Warning(drivers/regulator/core.c:3750): No description found for parameter 'dev' Sep 06 To Miklos Szere ( 20:0) [vfs:for-miklos 34/43] Warning(fs/dcache.c:1167): No description found for parameter 'data' Sep 10 To Waiman Long ( 22:0) [vfs:for-next 9/10] Warning(fs/dcache.c:102): No description found for parameter 'lock' Sep 11 To Lars-Peter C ( 25:0) [xlnx:master-next 96/99] Warning(drivers/gpu/drm/drm_edid.c:1061): No description found for parameter 'data' Sep 12 To Brian Norris ( 13:0) [l2-mtd:master 9/11] Warning(include/linux/mtd/nand.h:587): Excess struct/union/enum/typedef member 'ecclayout' Does that sound enough? Thanks, Fengguang -- 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: "memory" binding issues
On Tue, Sep 17, 2013 at 4:04 PM, Benjamin Herrenschmidt wrote: > On Tue, 2013-09-17 at 14:33 -0700, Olof Johansson wrote: >> > I don't think it's broken, why do you think so? It's at least >> consistent. >> > Probably not perfect and not complete, but IMHO a reasonable base >> for >> > further work. (Also at least something written down that people can >> learn >> > from and/or refer to.) >> >> So, I stand corrected. It seems that at least one legacy system I'm >> looking at always specifies unit address as well. I don't like it but >> I'll stop arguing. >> >> Ben: The interesting part is that it does _not_ specify it on /memory >> though. Nor, of course, on /cpus or /openprom. So assuming /memory@0 >> exists will break even on some powerpc platforms. > > What system is that out of curiosity ? Also make sure it's not just > Linux being an idiot and stripping the @0 in /proc/device-tree ... > > (I think some old versions of /proc code would strip it) > > Or is that some insanely broken OF like Apple old world or Pegasos ? > > If it's just embedded .dts files, yes, I fixed some, but we might still > have some bad ones. The only powerpc hardware I still have these days is PA Semi systems, so it's from one of them, with current -next kernel. Booted with OF client interface, no dts file that can be fixed. > In any case, we all agree, the right thing to do first is to fix our > path parser to cope either way. Yep, I just wanted to alert you that there's powerpc systems out there with just /memory as well. -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 5/6] sparc: Use preempt_schedule_irq
On Tue, 17 Sep 2013, David Miller wrote: > From: Thomas Gleixner > Date: Tue, 17 Sep 2013 18:53:08 - > > > bne,pn %xcc, kern_fpucheck > > -sethi %hi(PREEMPT_ACTIVE), %l6 > > - stw %l6, [%g6 + TI_PRE_COUNT] > > - callschedule > > + callpreempt_schedule_irq > > nop > > You've put the function call into the delay slot of the branch, > which you don't want to do. > > That's, btw, why we indent instructions with an extra space like > that, to emphasize that it's a delay slot of the preceeding > branch. I knew that I'd get it wrong :) So is adding another nop the right thing to do ? bne,pn %xcc, kern_fpucheck -sethi %hi(PREEMPT_ACTIVE), %l6 - stw %l6, [%g6 + TI_PRE_COUNT] - callschedule +nop + callpreempt_schedule_irq nop Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] RX-51: ARM errata 430973 workaround
* Pali Rohár [130710 06:06]:
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
This file will be gone as soon as we're moving to device
tree based booting. So let's do this in more future proof
way.
> +/**
> + * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
> + * @idx: The PPA API index
> + * @process: Process ID
> + * @flag: The flag indicating criticality of operation
> + * @nargs: Number of valid arguments out of four.
> + * @arg1, arg2, arg3 args4: Parameters passed to secure API
> + *
> + * Return the non-zero error value on failure.
> + */
> +static u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
> +u32 arg1, u32 arg2, u32 arg3, u32 arg4)
> +{
> + u32 ret;
> + u32 param[5];
> +
> + param[0] = nargs+1; /* RX-51 needs number of arguments + 1 */
> + param[1] = arg1;
> + param[2] = arg2;
> + param[3] = arg3;
> + param[4] = arg4;
> +
> + /*
> + * Secure API needs physical address
> + * pointer for the parameters
> + */
> + local_irq_disable();
> + local_fiq_disable();
> + flush_cache_all();
> + outer_clean_range(__pa(param), __pa(param + 5));
> + ret = omap_smc3(idx, process, flag, __pa(param));
> + flush_cache_all();
> + local_fiq_enable();
> + local_irq_enable();
> +
> + return ret;
> +}
I think this used to be in omap-secure.c, and then made rx51
specific.. But since board-rx51.c is going away, let's move
this function to omap-secure.c.
> + * rx51_secure_update_aux_cr: Routine to modify the contents of Auxiliary
> Control Register
> + * @set_bits: bits to set in ACR
> + * @clr_bits: bits to clear in ACR
> + *
> + * Return the non-zero error value on failure.
> +*/
> +static u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits)
> +{
> + u32 acr;
> +
> + /* Read ACR */
> + asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
> + acr &= ~clear_bits;
> + acr |= set_bits;
> +
> + return rx51_secure_dispatcher(RX51_PPA_WRITE_ACR,
> + 0,
> + FLAG_START_CRITICAL,
> + 1, acr, 0, 0, 0);
> +}
This too.
> static void __init rx51_init(void)
> {
> struct omap_sdrc_params *sdrc_params;
> @@ -105,6 +175,14 @@ static void __init rx51_init(void)
> rx51_peripherals_init();
> rx51_camera_init();
>
> + if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
> +#ifdef CONFIG_ARM_ERRATA_430973
> + pr_info("RX-51: Enabling ARM errata 430973 workaround\n");
> + /* set IBE to 1 */
> + rx51_secure_update_aux_cr(BIT(6), 0);
> +#endif
> + }
> +
> /* Ensure SDRC pins are mux'd for self-refresh */
> omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
> omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Then this can be called both from board-generic.c based on the
compatible flag, and board-rx51.c for now.
Regards,
Tony
--
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: increased vmap_area_lock contentions on "n_tty: Move buffers into n_tty_data"
On Tue, Sep 17, 2013 at 11:34:21AM -0400, Peter Hurley wrote: > On 09/12/2013 09:09 PM, Fengguang Wu wrote: > >On Fri, Sep 13, 2013 at 08:51:33AM +0800, Fengguang Wu wrote: > >>Hi Peter, > >> > >>FYI, we noticed much increased vmap_area_lock contentions since this > >>commit: > >> > >>commit 20bafb3d23d108bc0a896eb8b7c1501f4f649b77 > >>Author: Peter Hurley > >>Date: Sat Jun 15 10:21:19 2013 -0400 > >> > >> n_tty: Move buffers into n_tty_data > >> > >> Reduce pointer reloading and improve locality-of-reference; > >> allocate read_buf and echo_buf within struct n_tty_data. > > > >Here are some comparison between this commit [o] with its parent commit [*]. > > Hi Fenguang, > > Can you give the particulars of the aim7 test runs below? > I ask because I get _no_ added contention on the vmap_area_lock when I run > these tests on a dual-socket xeon. > > What is the machine configuration(s)? > Are you using the aim7 'multitask' test driver or your own custom driver? > What is the load configuration (ie., constant, linearly increasing, > convergence)? > How many loads are you simulating? The aim7 tests are basically ( echo $HOSTNAME echo $workfile echo 1 echo 2000 echo 2 echo 2000 echo 1 ) | ./multitask -t >lock_stat.vmap_area_lock.holdtime-total > [...] > >489739.50 +978.5% 5281916.05 > > lkp-ne04/micro/aim7/shell_rtns_1 > > 1601675.63 +906.7% 16123642.52 > > lkp-snb01/micro/aim7/exec_test > [...] > >822461.02 +1585.0% 13858430.62 > > nhm-white/micro/aim7/exec_test > > 9858.11 +2715.9%277595.41 > > nhm-white/micro/aim7/fork_test > [...] > > 300.14 +2621.5% 8168.53 > > nhm-white/micro/aim7/misc_rtns_1 > >345479.21 +1624.5% 5957828.25 > > nhm-white/micro/aim7/shell_rtns_1 > > > None of the tests below execute a code path that leads to get_vmalloc_info(). > The only in-kernel user of get_vmalloc_info() is a sysfs read of > /proc/meminfo, > which none of the tests below perform. > > What is reading /proc/meminfo? Good point! That may explain it: I'm running a loop: cat /proc/meminfo sleep 1 in all the tests. Thanks, Fengguang > > lock_stat.vmap_area_lock.contentions.get_vmalloc_info > > > > 8cb06c983822103da1cf 20bafb3d23d108bc0a89 > > > > 4952.40 +447.0% 27090.40 > > lkp-ne04/micro/aim7/shell_rtns_1 > > 28410.80 +556.2%186423.00 > > lkp-snb01/micro/aim7/exec_test > > 8142.00 +615.4% 58247.33 > > nhm-white/micro/aim7/exec_test > > 1386.00 +762.6% 11955.20 > > nhm-white/micro/aim7/shell_rtns_1 > > 42891.20 +561.5%283715.93 TOTAL > > lock_stat.vmap_area_lock.contentions.get_vmalloc_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/
Re: [PATCH] clockevents: Sanitize ticks to nsec conversion
On Wed, 18 Sep 2013, Marc Kleine-Budde wrote: > On 09/17/2013 11:15 PM, Thomas Gleixner wrote: > > Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use > > clockevents_config_and_register() where possible" caused a regression > > for some of the converted subarchs. > > > > The reason is, that the clockevents core code converts the minimal > > hardware tick delta to a nanosecond value for core internal > > usage. This conversion is affected by integer math rounding loss, so > > the backwards conversion to hardware ticks will likely result in a > > value which is less than the configured hardware limitation. The > > affected subarchs used their own workaround (SIGH!) which got lost in > > the conversion. > > > > Now instead of fixing the underlying core code problem, Marcs patch > > tried to work around the core code issue by increasing the minimal > > tick delta at clockevents registration time so the resulting limit in > > the core code backwards conversion did not violate the hardware > > limits. More SIGH! > > It was not easy getting your attention with this problem :) A really hard to understand and solve problem! Obviously you are a great fan of John Stultz famous "Math is hard, lets go shopping!" line. Why on earth do you need my attention to fix at least the simple rounding issue in the core code? You could have sent the "clk += evt->mult - 1:" patch directly to Linus without even cc'ing me. It's not rocket science, really. When I responded with the while(1) loop patch today in the morning it was just because I did not have a second to think about the correct fix for this, but the reason WHY this happened was entirely clear in a split second after reading Russells reply. The upper bounds issue tooks a few minutes more, but it's not rocket science either. Sorry, I can understand the need for a second opinion on a weird race condition problem, but tracking down an obvious simple math issue to the point and fixing it... SIGH! Thanks, tglx -- 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] KVM: cleanup (physical) CPU hotplug
Il 17/09/2013 09:57, Jan Kiszka ha scritto: >> > Remove the useless argument, and do not do anything if there are no >> > VMs running at the time of the hotplug. > kvm_cpu_hotplug already filters !kvm_usage_count. If we need the check > to be under kvm_lock, drop that line as well. If that is not required > (machine still halted?), drop the related changes here. CPU_DYING is called under stop_machine, CPU_STARTING is not. So I should drop the test in kvm_cpu_hotplug. It's a bit clearer anyway to not rely on stop_machine. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] lib: Add .config options for error strings in printks
On 09/17/2013 06:08 PM, danielfsan...@att.net wrote: --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -58,6 +58,7 @@ config DYNAMIC_DEBUG implicitly compiles in all pr_debug() and dev_dbg() calls, which enlarges the kernel text size by about 2%. + If a source file is compiled with DEBUG flag set, any pr_debug() calls in it are enabled by default, but can be disabled at runtime as below. Note that DEBUG flag is @@ -113,6 +114,58 @@ config DYNAMIC_DEBUG whoops! Please ignore this carriage return! :) -- 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 v4 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
* Pali Rohár [130917 09:01]: > On Tuesday 17 September 2013 17:43:31 Tony Lindgren wrote: > > Have you guys checked how this works with the recently posted > > "[PATCH v6 0/5] ARM: support for Trusted Foundations secure > > monitor" series? > > this code looks like some Tegra and "Trusted Foundations" > specific. There is Note: The API followed by Trusted Foundations > does *not* follow the SMC calling conventions. Also code calling > smc #0 instruction, so in my opinion for rx51 it is useless. OK, so still no generic SMC code then :( This patch is fine with me. > Tony, can you include this two rx51 secure patches (patch v4 1/2 > and patch v2 2/2)? Or is there some any other problem? No other comments on this patch, I'll post some comments on the v2 2/2 patch considering we're moving to device tree based booting. Regards, Tony -- 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 4/5] lib: Add strerror and strerror_name functions
Signed-off-by: Daniel Santos
---
include/linux/string.h | 8 +++
lib/string.c | 60 ++
2 files changed, 68 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index ac889c5..76ce2ff 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -154,4 +154,12 @@ static inline const char *kbasename(const char *path)
return tail ? tail + 1 : path;
}
+#ifdef CONFIG_STRERROR
+extern const char *strerror(int error);
+#endif
+
+#ifdef CONFIG_STRERROR_NAME
+extern const char *strerror_name(int error);
+#endif
+
#endif /* _LINUX_STRING_H_ */
diff --git a/lib/string.c b/lib/string.c
index e5878de..7fd2704 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -27,6 +27,10 @@
#include
#include
+#if defined(CONFIG_STRERROR) || defined(CONFIG_STRERROR_NAME)
+# include
+#endif
+
#ifndef __HAVE_ARCH_STRNICMP
/**
* strnicmp - Case insensitive, length-limited string comparison
@@ -824,3 +828,59 @@ void *memchr_inv(const void *start, int c, size_t bytes)
return check_bytes8(start, value, bytes % 8);
}
EXPORT_SYMBOL(memchr_inv);
+
+#if defined(CONFIG_STRERROR) || defined(CONFIG_STRERROR_NAME)
+static const char *_strerror(int error, unsigned index)
+{
+ unsigned uerror = error < 0 ? -error : error;
+ const struct error_strings *es;
+ const struct error_strings *es_end = _strings[
+ sizeof(error_strings) / sizeof(*error_strings)];
+ const char *ret;
+ unsigned i;
+
+ for (es = error_strings; es != es_end; ++es) {
+ if (uerror >= es->first && uerror <= es->last)
+ break;
+ }
+
+ if (es == es_end)
+ return NULL;
+
+ for (i = es->first, ret = es->desc[index]; i < uerror; ++ret)
+ i += !*ret;
+
+ BUG_ON(i > es->last);
+ BUG_ON(i != uerror);
+
+ return *ret ? ret : NULL;
+}
+#endif /* defined(CONFIG_STRERROR) || defined(CONFIG_STRERROR_NAME) */
+
+#ifdef CONFIG_STRERROR
+/**
+ * strerror - Translates an error code into a description.
+ * @error: The error to describe (may be positive or negative)
+ *
+ * Returns a pointer to the error description or NULL if none is found.
+ */
+const char *strerror(int error)
+{
+ return _strerror(error, 1);
+}
+EXPORT_SYMBOL(strerror);
+#endif
+
+#ifdef CONFIG_STRERROR_NAME
+/**
+ * strerror_name - Translates an error code into a name
+ * @error: The error to describe (may be positive or negative)
+ *
+ * Returns a pointer to the error name or NULL if none is found.
+ */
+const char *strerror_name(int error)
+{
+ return _strerror(error, 0);
+}
+EXPORT_SYMBOL(strerror_name);
+#endif
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: old trees
Hi Sekhar, On Tue, 17 Sep 2013 16:44:32 +0530 Sekhar Nori wrote: > > You can remove the davinci tree from linux-next since the patches are > now reaching linux-next through ARM-SoC tree. Apologies for not asking > you to remove it for so long. Done. -- Cheers, Stephen Rothwell s...@canb.auug.org.auhttp://www.canb.auug.org.au/~sfr/ pgpORzhZOsCvC.pgp Description: PGP signature
[PATCH 3/5] Makefile: Generate error_strings.h
This is an initial attempt and needs improvement. Ideally, error_strings.h should only be generated when STRERROR or STRERROR_NAME are enabled. This implementation also fails to remake error_strings.h when arch-specific dependencies change. Also, I've noticed that this implementation fails to output a message when it's running, so help with this would be appreciated. Signed-off-by: Daniel Santos --- Makefile | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8243a23..38049ca 100644 --- a/Makefile +++ b/Makefile @@ -835,7 +835,7 @@ endif prepare2: prepare3 outputmakefile asm-generic prepare1: prepare2 $(version_h) include/generated/utsrelease.h \ - include/config/auto.conf + include/config/auto.conf include/generated/error_strings.h $(cmd_crmodverdir) archprepare: archheaders archscripts prepare1 scripts_basic @@ -873,6 +873,13 @@ $(version_h): $(srctree)/Makefile FORCE include/generated/utsrelease.h: include/config/kernel.release FORCE $(call filechk,utsrelease.h) +include/generated/error_strings.h: include/uapi/asm-generic/errno-base.h \ + include/uapi/asm-generic/errno.h \ + include/uapi/linux/errno.h \ + include/linux/errno.h + $(shell ARCH=$(ARCH) $(srctree)/scripts/mkstrerror.sh \ + > $(srctree)/include/generated/error_strings.h) + PHONY += headerdep headerdep: $(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \ -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] lib: Add error string support to printks
This adds an extension for the integral format specifier suffix of 'e',
so that the format %[duxXo]e will result in printing an number (as
before) in addition to a name and descrption for an error code, if such
support is enabled and a name and descrption is found.
My initial thought was to use the glibc extension of '%m', but this
format specifier uses the value of libc's errno and adding a value
breaks gcc's printf parsing. I'm not convinced that the 'e' extension
is optimal, although there are only four instances of this pattern in
the kernel that would need to be changed.
git grep -E '".*%[#0\ +\-]*[0-9]*[hljzt]*[idoxXu]e'
Alternatively, 'E' was another thought for a suffix as well.
Signed-off-by: Daniel Santos
---
lib/vsprintf.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..d96d675 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -345,6 +345,12 @@ int num_to_str(char *buf, int size, unsigned long long num)
#define SMALL 32 /* use lowercase in hex (must be 32 == 0x20) */
#define SPECIAL64 /* prefix hex with "0x", octal with "0"
*/
+#if defined(CONFIG_PRINTK_ERROR_NAMES) || defined(CONFIG_PRINTK_ERROR_DESCS)
+# define ERROR 128 /* error name and/or descrption */
+#else
+# define ERROR 0
+#endif
+
enum format_type {
FORMAT_TYPE_NONE, /* Just a string part */
FORMAT_TYPE_WIDTH,
@@ -1346,6 +1352,75 @@ char *pointer(const char *fmt, char *buf, char *end,
void *ptr,
return number(buf, end, (unsigned long) ptr, spec);
}
+/**
+ * error - format an error code into a descrption
+ *
+ * Basically, we print the number, name and descrption, but only if enabled.
+ * If there is no string for an error number, it's printed as if the option is
+ * disabled. The format is basically equivalent to:
+ *
+ * printk("%d (%s: %s)", num, name, descrption);
+ *
+ * If there's no descrption, it would end up like:
+ *
+ * printk("%d (%s)", num, name);
+ *
+ * etc.
+ *
+ * Note that we ignore width and precision here, although they are applied to
+ * the numerical portion of the output in number().
+ *
+ * Since we're initializing desc to NULL and then only setting it based upon
+ * a pre-compiler constant value, all code expecting it to be non-zero should
+ * compile-out when CONFIG_PRINTK_ERROR_DESCS is not enabled.
+ */
+#if defined(CONFIG_PRINTK_ERROR_NAMES) || defined(CONFIG_PRINTK_ERROR_DESCS)
+static noinline_for_stack
+char *error(char *buf, char *end, int err, struct printf_spec spec)
+{
+ const char *name = strerror_name(err);
+ const char *desc = NULL;
+
+#if defined(CONFIG_PRINTK_ERROR_DESCS)
+ desc = strerror(err);
+#endif
+
+ if (!(name || desc))
+ return buf;
+
+ if ([1] < end) {
+ *buf++ = ' ';
+ *buf++ = '(';
+ }
+
+ if (name)
+ while (buf < end && *name)
+ *buf++ = *name++;
+
+ if (desc) {
+ if (name && [1] < end) {
+ *buf++ = ':';
+ *buf++ = ' ';
+ }
+
+ while (buf < end && *desc)
+ *buf++ = *desc++;
+ }
+
+ if (buf < end)
+ *buf++ = ')';
+
+ return buf;
+}
+#else
+static inline
+char *error(char *buf, char *end, int err, struct printf_spec spec)
+{
+ return buf;
+}
+#endif /* CONFIG_PRINTK_ERROR_NAMES || CONFIG_PRINTK_ERROR_DESCS */
+
+
/*
* Helper function to decode printf style format.
* Each call decode a token from the format and return the
@@ -1501,12 +1576,20 @@ qualifier:
case 'X':
spec->base = 16;
+ if (fmt[1] == 'e') {
+ spec->flags |= ERROR;
+ ++fmt;
+ }
break;
case 'd':
case 'i':
spec->flags |= SIGN;
case 'u':
+ if (fmt[1] == 'e') {
+ spec->flags |= ERROR;
+ ++fmt;
+ }
break;
default:
@@ -1577,6 +1660,9 @@ qualifier:
* %*ph[CDN] a variable-length hex string with a separator (supports up to 64
* bytes of the input)
* %n is ignored
+ * %[idxXu]e will print the name of error code, if one exists. If the number
+ * doesn't match a known error code, it is printed as a normal signed int.
+ * TODO: explain CONFIG_PRINTK_ERROR*
*
* ** Please update Documentation/printk-formats.txt when making changes **
*
@@ -1738,6 +1824,9 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
}
str = number(str, end, num, spec);
+
+ if (spec.flags & ERROR)
+ str = error(str, end, num, spec);
}
}
@@ -2185,6 +2274,9 @@ int
Re: linux-next: old trees
Hi Josh, On Tue, 17 Sep 2013 08:53:16 -0400 Josh Boyer wrote: > > > 4xx 1 year, 4 months ago > > This is subarch is basically in maintenance mode. There have only > been a handful of patches that have been submitted over the past year, > and I've ACKed them for Ben to bring in via his tree. The arch isn't > dead, but it's certainly not going to have much in the way of new > changes. The overall powerpc tree is probably sufficient for > linux-next. Removed. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgps75UbSiVVz.pgp Description: PGP signature
[PATCH 2/2] uinput: Support injecting multiple events in one write() call
Rework the code in uinput_inject_event so that it matches the code in
evdev_write and allows injecting more than one event, or zero events.
Signed-off-by: Ryan Mallon
---
drivers/input/misc/uinput.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index a0a4bba..0247a8a 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -434,16 +434,24 @@ static ssize_t uinput_inject_event(struct uinput_device
*udev,
const char __user *buffer, size_t count)
{
struct input_event ev;
+ size_t bytes = 0;
- if (count < input_event_size())
+ if (count != 0 && count < input_event_size())
return -EINVAL;
- if (input_event_from_user(buffer, ))
- return -EFAULT;
+ while (bytes + input_event_size() <= count) {
+ if (input_event_from_user(buffer + bytes, )) {
+ if (!bytes)
+ bytes = -EFAULT;
+ goto out;
+ }
- input_event(udev->dev, ev.type, ev.code, ev.value);
+ input_event(udev->dev, ev.type, ev.code, ev.value);
+ bytes += input_event_size();
+ }
- return input_event_size();
+ out:
+ return bytes;
}
static ssize_t uinput_write(struct file *file, const char __user *buffer,
--
1.7.9.7
--
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] audit: avoid soft lockup in audit_log_start()
On Tue, 17 Sep 2013 15:28:42 -0700
Andrew Morton wrote:
> On Tue, 10 Sep 2013 12:03:25 -0400 Eric Paris wrote:
>
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -1215,9 +1215,10 @@ struct audit_buffer *audit_log_start(struct
> > > audit_context *ctx, gfp_t gfp_mask,
> > >
> > > sleep_time = timeout_start +
> > > audit_backlog_wait_time -
> > > jiffies;
> > > - if ((long)sleep_time > 0)
> > > + if ((long)sleep_time > 0) {
> > > wait_for_auditd(sleep_time);
> > > - continue;
> > > + continue;
> > > + }
> > > }
> > > if (audit_rate_check() && printk_ratelimit())
> > > printk(KERN_WARNING
> >
> > I think this is the right(ish) fix, at least it gets at the real bug.
> > 829199197a430dade2519d54f5545c4a094393b8 definitely is the problem.
>
> um, which idiot wrote that?
LOL!
> Thngs are somewhat foggy at present. I have two patches from
> Dan/Chuck:
>
> Subject: audit: fix soft lockups due to loop in audit_log_start() wh,en
> audit_backlog_limit exceeded
> Subject: audit: two efficiency fixes for audit mechanism
>
> and two from Luiz:
>
> Subject: audit: flush_hold_queue(): don't drop queued SKBs
> Subject: audit: kaudit_send_skb(): make non-blocking call to netlink_unicast()
>
> and now a protopatch from Konstantin which eparis likes.
>
> So, umm, guys, can you please devote a bit of time to working out what
> we should do here?
You can drop my patches. Konstantin's patch is a better version of my
first RFC. My second series is kind of a new concept which the audit
team seems to disagree with, and I won't push hard on 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/
[PATCH 1/5] scripts: Add mkstrerror.sh
This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.
First it looks at $ARCH and examines the errno.h files and figures out
which to use. Then, it parses their error definitions into a
pipe-character delimited table with the fields name, number and
descrption from the comments. Finally, it does some consistency checks
and output them as usable C code.
On my Phenom it takes between 1.2 and 2 seconds to run depending upon
the arch. There are a few arch-specific conditions that the script has
to manage however:
* alpha: EAGAIN is redefined as 35 while EDEADLK is defined as 11
* mips: EDQUOT is 1133, which overlaps the internal error range
(512-529), so I'm just removing it.
This is done in a little case $ARCH statement in parse_errors().
Signed-off-by: Daniel Santos
---
scripts/mkstrerror.sh | 209 ++
1 file changed, 209 insertions(+)
create mode 100755 scripts/mkstrerror.sh
diff --git a/scripts/mkstrerror.sh b/scripts/mkstrerror.sh
new file mode 100755
index 000..e7842fc
--- /dev/null
+++ b/scripts/mkstrerror.sh
@@ -0,0 +1,209 @@
+#!/bin/bash
+
+# Generate lib/error_names.h by parsing errno*.h files
+
+typeset -i first=0
+typeset -i last=0
+typeset -i count=0
+
+die() {
+ echo "ERROR: $*" >&2
+ exit 1
+}
+
+parse_errors() {
+ egrep -h '^#define\s+\w+\s+[0-9]+' "$@" | # Extract error definitions
+ case "${ARCH}" in # Apply per-arch fixups
+ alpha) egrep -v 'EAGAIN\s+11';;
+ mips) egrep -v 'EDQUOT\s+1133';;
+ *) cat;;
+ esac |
+ perl -pe '
+ # Replace missing comments with "/* \0 */"
+ s:(\d+)\s*$:$1 /\* \\0 \*/\n:g;
+
+ # Parse into pipe-delimited table
+ s:^#define\s+(\w+)\s+(\w+)\s+/\*\s+(.*?)\s+\*/:$1|$2|$3:g;
+
+ # Since we will be feeding this to printf later, double any
+ # occurrence of %
+ s:%:%%:g;
+ ' |
+ sort '-t|' -nk2 # Sort by error number
+}
+
+tab_align() {
+ typeset -i tabs=$1
+ typeset -i next=0
+ typeset -i i
+ typeset -i len
+ local s
+ shift
+
+ while (($#)); do
+ for (( i = 0; i < next; ++i)); do
+ printf "\t"
+ done
+
+ printf "$1"
+
+ # Get un-escaped string size
+ s=$(printf "$1")
+ (( next = tabs - (${#s} ) / 8 ))
+ shift
+ done
+}
+
+print_errors() {
+ typeset -i next_err=$1
+ typeset -i tabs=$2
+ typeset -i errnum
+ local errname
+ while read; do
+ errnum=${REPLY/*|/}
+ errname=${REPLY/|*/}
+
+ (( next_err <= errnum )) || die "errors out of order :("
+
+ # Fill in any gaps with empty names
+ while (( next_err < errnum )); do
+ printf "\t%s\n" "$(tab_align ${tabs} '"\\0"' "/*
${next_err} */\n")"
+ (( ++next_err ))
+ done
+
+ printf "\t%s\n" "$(tab_align ${tabs} "\"${errname}"'\\0"' "/*
${errnum} */\n")"
+ (( ++next_err ))
+ done
+
+}
+
+count_and_validate() {
+ local names="$1"
+ typeset -i expected_count
+
+ first=$(echo "${names}" | head -1 | awk '{print $3}')
+ last=$(echo "${names}" | tail -1 | awk '{print $3}')
+ count=$(echo "${names}" | wc -l)
+ expected_count=$((last - first + 1))
+
+ if (( count != expected_count )); then
+ echo "ERROR: count = ${count}, expected ${expected_count}"
+ return 1;
+ fi
+ return 0;
+}
+
+find_arch_errno() {
+ for d in $(find arch/${ARCH}/include -name errno.h); do
+ # If it just includes asm-generic/errno.h then skip it
+ if ! grep '#include ' $d > /dev/null; then
+ arch_errno="$d"
+ return;
+ fi
+ done
+
+ # Otherwise, no arch-specific errno
+ arch_errno=include/uapi/asm-generic/errno.h
+}
+
+find_arch_errno
+
+base_err_table=$(
+ parse_errors include/uapi/asm-generic/errno-base.h ${arch_errno}
+) || die
+
+internal_err_table=$(
+ parse_errors include/linux/errno.h
+) || die
+
+base_err_names=$(
+ echo "${base_err_table}" |
+ perl -pe 's:(\d+)\|.*:$1:g;'|
+ print_errors 0 4
+) || die
+
+count_and_validate "${base_err_names}" || die
+typeset -i base_err_first=${first}
+typeset -i base_err_last=${last}
+typeset -i base_err_count=${count}
+
+int_err_names=$(
+ echo "${internal_err_table}" |
+ perl -pe 's:(\d+)\|.*:$1:g;'|
+ print_errors 512 4
+) || die
+
+count_and_validate "${int_err_names}" || die
+typeset -i int_err_first=${first}
Re: [PATCH v4 0/3] cleanup of gpio_pcf857x.c
Hi Linus, On Tuesday 17 September 2013 14:51:48 Linus Walleij wrote: > On Wed, Sep 4, 2013 at 9:03 AM, George Cherian wrote: > > This patch series > > > > - removes the irq_demux_work > > - Uses devm_request_threaded_irq > > - Call the user handler iff gpio_to_irq is done. > > > > v1 --> v2 > > > > Split v1 to 3 patches > > > > v2 --> v3 > > > > Remove the unnecessary dts patches. > > > > v3 --> v4 > > > > Remove gpio->irq (in patch 2) > > Applied all three patches with Kuninoro's ACK. > > However your last iteration was still labeled "v3" in the subject > so I was a bit confused, but I took all those sent on sep 4. > > Please check the result in my GPIO tree or linux-next and > make sure it works. > > > Note: these patches were made after applying [1]. > > [1] - [PATCH v5] gpio: pcf857x: Add OF support - > > https://lkml.org/lkml/2013/8/27/70 > > Well that patch is not finished, but by rebasing patch 2 with > patch -p1 < patch2.patch it applied anyway. > > Now Laurent has to finalize his DT bindings on top of your patches instead. I will do so. At first sight I don't see any conflict issue. -- Regards, Laurent Pinchart -- 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 5/6] sparc: Use preempt_schedule_irq
From: Thomas Gleixner Date: Tue, 17 Sep 2013 18:53:08 - > bne,pn %xcc, kern_fpucheck > - sethi %hi(PREEMPT_ACTIVE), %l6 > - stw %l6, [%g6 + TI_PRE_COUNT] > - callschedule > + callpreempt_schedule_irq >nop You've put the function call into the delay slot of the branch, which you don't want to do. That's, btw, why we indent instructions with an extra space like that, to emphasize that it's a delay slot of the preceeding branch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] module: Make wait module's refcount to zero procedure as async
On Mon, Sep 16, 2013 at 12:47 AM, Rusty Russell wrote:
> Lucas De Marchi writes:
>> On Thu, Sep 12, 2013 at 9:30 PM, Rusty Russell wrote:
>>> Peter Chen writes:
Currently, if module's refcount is not zero during the unload,
it waits there until the user decreases that refcount.
>>>
>>> Hi Peter,
>>>
>>> In practice userspace uses O_NONBLOCK. In fact, I've been
>>> thinking of removing the blocking case altogether, since it's not really
>>> what people want.
>>>
>>> That would solve your problem and make the code simpler. Thoughts?
>>
>> I'm all in favor of this. It's been almost 1 year it's deprecated in
>> kmod and if anyone tries to use we force a 10s delay on module
>> removal. So far nobody complained.
>>
>> Lucas De Marchi
>
> Here's what I've got in my pending-rebases tree.
>
> Cheers,
> Rusty.
>
> module: remove rmmod --wait option.
>
> The option to wait for a module reference count to reach zero was in
> the initial module implementation, but it was never supported in
> modprobe (you had to use rmmod --wait). After discussion with Lucas,
> It has been deprecated (with a 10 second sleep) in kmod for the last
> year.
>
> This finally removes it: the flag will evoke a printk warning and a
> normal (non-blocking) remove attempt.
>
> Cc: Lucas De Marchi
> Signed-off-by: Rusty Russell
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 05f2447..15cd6b1 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -367,9 +367,6 @@ struct module
> /* What modules do I depend on? */
> struct list_head target_list;
>
> - /* Who is waiting for us to be unloaded */
> - struct task_struct *waiter;
> -
> /* Destruction function. */
> void (*exit)(void);
>
> diff --git a/kernel/module.c b/kernel/module.c
> index dc58274..947105f 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -644,8 +644,6 @@ static int module_unload_init(struct module *mod)
>
> /* Hold reference count during initialization. */
> __this_cpu_write(mod->refptr->incs, 1);
> - /* Backwards compatibility macros put refcount during init. */
> - mod->waiter = current;
>
> return 0;
> }
> @@ -771,16 +769,9 @@ static int __try_stop_module(void *_sref)
>
> static int try_stop_module(struct module *mod, int flags, int *forced)
> {
> - if (flags & O_NONBLOCK) {
> - struct stopref sref = { mod, flags, forced };
> + struct stopref sref = { mod, flags, forced };
>
> - return stop_machine(__try_stop_module, , NULL);
> - } else {
> - /* We don't need to stop the machine for this. */
> - mod->state = MODULE_STATE_GOING;
> - synchronize_sched();
> - return 0;
> - }
> + return stop_machine(__try_stop_module, , NULL);
> }
>
> unsigned long module_refcount(struct module *mod)
> @@ -813,21 +804,6 @@ EXPORT_SYMBOL(module_refcount);
> /* This exists whether we can unload or not */
> static void free_module(struct module *mod);
>
> -static void wait_for_zero_refcount(struct module *mod)
> -{
> - /* Since we might sleep for some time, release the mutex first */
> - mutex_unlock(_mutex);
> - for (;;) {
> - pr_debug("Looking at refcount...\n");
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - if (module_refcount(mod) == 0)
> - break;
> - schedule();
> - }
> - current->state = TASK_RUNNING;
> - mutex_lock(_mutex);
> -}
> -
> SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
> unsigned int, flags)
> {
> @@ -842,6 +818,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
> name_user,
> return -EFAULT;
> name[MODULE_NAME_LEN-1] = '\0';
>
> + if (!(flags & O_NONBLOCK)) {
> + printk(KERN_WARNING
> + "waiting module removal not supported: please
> upgrade");
> + }
> +
> if (mutex_lock_interruptible(_mutex) != 0)
> return -EINTR;
>
> @@ -859,8 +840,7 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
> name_user,
>
> /* Doing init or already dying? */
> if (mod->state != MODULE_STATE_LIVE) {
> - /* FIXME: if (force), slam module count and wake up
> - waiter --RR */
> + /* FIXME: if (force), slam module count damn the torpedoes */
> pr_debug("%s already dying\n", mod->name);
> ret = -EBUSY;
> goto out;
> @@ -876,18 +856,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
> name_user,
> }
> }
>
> - /* Set this up before setting mod->state */
> - mod->waiter = current;
> -
> /* Stop the machine so refcounts can't move and disable module. */
> ret = try_stop_module(mod, flags, );
> if (ret != 0)
[PATCH 1/2] input: Return the number of bytes written so far on evdev write failure
If input_event_from_user() fails in evdev write() and at least one
event has been written successfully then return the number of bytes
written. If no events have been written, then the EFAULT error is
returned.
Signed-off-by: Ryan Mallon
---
drivers/input/evdev.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index d2b34fb..b0dec2ba 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -437,7 +437,8 @@ static ssize_t evdev_write(struct file *file, const char
__user *buffer,
while (retval + input_event_size() <= count) {
if (input_event_from_user(buffer + retval, )) {
- retval = -EFAULT;
+ if (retval == 0)
+ retval = -EFAULT;
goto out;
}
retval += input_event_size();
--
1.7.9.7
--
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: "memory" binding issues
On Tue, 2013-09-17 at 14:33 -0700, Olof Johansson wrote: > > I don't think it's broken, why do you think so? It's at least > consistent. > > Probably not perfect and not complete, but IMHO a reasonable base > for > > further work. (Also at least something written down that people can > learn > > from and/or refer to.) > > So, I stand corrected. It seems that at least one legacy system I'm > looking at always specifies unit address as well. I don't like it but > I'll stop arguing. > > Ben: The interesting part is that it does _not_ specify it on /memory > though. Nor, of course, on /cpus or /openprom. So assuming /memory@0 > exists will break even on some powerpc platforms. What system is that out of curiosity ? Also make sure it's not just Linux being an idiot and stripping the @0 in /proc/device-tree ... (I think some old versions of /proc code would strip it) Or is that some insanely broken OF like Apple old world or Pegasos ? If it's just embedded .dts files, yes, I fixed some, but we might still have some bad ones. In any case, we all agree, the right thing to do first is to fix our path parser to cope either way. Cheers, Ben. -- 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 4/4] drivers: net: phy: cicada.c: clears warning Use #include instead of
From: Avinash Kumar Date: Mon, 16 Sep 2013 21:39:41 +0530 > clears following warnings : > WARNING: Use include instead of > WARNING: Use include instead of > > Signed-off-by: Avinash Kumar Applied, thanks. -- 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 0/5] Preliminary: Add error names & descrptions to printks
This is a preliminary patch set as the root Makefile changes are not yet
correct.
Summary
Typically, we don't care about error messages or names in the kernel because
userspace will manage that. But sometimes we need to output an error number
to printks and that creates a situation where a user, system admistrator or
developer must find an error number reference to figure out what went wrong
with a particular driver or whatever. This patch adds two alternatives at
increasing memory costs:
1. print the number in addition to the name for 2k extra or
2. print the number, name and description for 6k extra.
This is fairly low cost for the person who wants to make life just a little
bit easier. The format of each is respectively the same as the following:
printk("%d (%s)", err, err_name);
printk("%d (%s: %s)", err, err_name, err_desc);
Theory
Error messages aren't printed often, so this data and code is designed to be
compact at the expense of speed. Rather than using an array of strings that
would require both the text and a pointer to that text, we just cram a range
of error names or descriptions into a single string with null character
delimiters. When we want to retrieve a string, we just iterate through that
string and count nulls. This is slow, but it keeps it compact. (If this
becomes a bottleneck then something else is seriously wrong! :)
--
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 2/5] lib: Add .config options for error strings in printks
This adds to lib/Kconfig.debug the options for printk messages to display either error number only (the current behavior), number and error name or number, name and description. These options in turn select STRERROR_NAME and STRERROR as needed, so I'm not adding any direct options to enable those, although it can be added later if somebody needs strerror() or strerror_name() when not enabled in printks. kconfg Signed-off-by: Daniel Santos --- lib/Kconfig.debug | 53 + 1 file changed, 53 insertions(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c9eef36..919f371 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -58,6 +58,7 @@ config DYNAMIC_DEBUG implicitly compiles in all pr_debug() and dev_dbg() calls, which enlarges the kernel text size by about 2%. + If a source file is compiled with DEBUG flag set, any pr_debug() calls in it are enabled by default, but can be disabled at runtime as below. Note that DEBUG flag is @@ -113,6 +114,58 @@ config DYNAMIC_DEBUG See Documentation/dynamic-debug-howto.txt for additional information. +choice + prompt "Display errors in printk as" + default PRINTK_ERROR_CODES_ONLY + depends on PRINTK + help + This option tells printk how to display error codes when + formatted with the %de format code (a Linux printk extension). + Error codes are most commonly passed to userspace when syscalls + return where they are then translated into localized descrptions + via libc's strerror(), perror(), etc. However, many error + conditions (for drivers and such) are only reported via printks + where there is no such userspace mechanism to reliably translate + error numbers into something a little more human. + + This option allows you to perform that translation in the kernel, + at the cost of a slightly larger kernel. Note that no native + language support is currently, or may ever be provided. + + If unsure, choose "Error codes only". + +config PRINTK_ERROR_CODES_ONLY + bool "Error codes only" + help + Just display the error number. + +config PRINTK_ERROR_NAMES + bool "Error names" + select STRERROR_NAME + help + This option causes printk messages containing an error code to + print the name of the error in addition to the error number. + Enabling this adds about 2k. Example: -22 (EINVAL) + +config PRINTK_ERROR_DESCS + bool "Full descrptions" + select STRERROR + select STRERROR_NAME + help + This option causes printk messages containing an error code to + print the description of errors (in addition to the name and + number) and can be helpful for those with aversions to search + engines. Enabling this adds about 6k over error codes alone. + Example: -90 (EMSGSIZE: Message too long) + +endchoice + +config STRERROR + bool + +config STRERROR_NAME + bool + endmenu # "printk and dmesg options" menu "Compile-time checks and compiler options" -- 1.8.1.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/
loan offer!!!
Do you need a loan? Do you need a loan that can be process within 2 to 3 working days? Have you been frustrated so many times by your banks and other loan firm. Here is the the Good news Midland Financial loan company is here to offer you any kind of loan you need. We give out loans to customer at an affordable interest loan. We Offer LOANS ranging from $20,000 USD Min to $50,000,000.00 USD Max. At 3%interest rate per annual. How much loan do you need ?. If you are interested let us know how much you need and your person information which Include your Full name address City/state , country, Telephone number , Amount Needed, loan Duration. Note: We offer personal loans, business loan , Home loans etc. Regards Mr.Mahindra George Financial Officer. Email: midlandl...@ufoff.co.in Tel: +919582455780 -- 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/
loan offer!!!
Do you need a loan? Do you need a loan that can be process within 2 to 3 working days? Have you been frustrated so many times by your banks and other loan firm. Here is the the Good news Midland Financial loan company is here to offer you any kind of loan you need. We give out loans to customer at an affordable interest loan. We Offer LOANS ranging from $20,000 USD Min to $50,000,000.00 USD Max. At 3%interest rate per annual. How much loan do you need ?. If you are interested let us know how much you need and your person information which Include your Full name address City/state , country, Telephone number , Amount Needed, loan Duration. Note: We offer personal loans, business loan , Home loans etc. Regards Mr.Mahindra George Financial Officer. Email: midlandl...@ufoff.co.in Tel: +919582455780 -- 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] sysv: Add forgotten superblock lock init for v7 fs
Superblock lock was replaced with (un)lock_super() removal, but left uninitialized for Seventh Edition UNIX filesystem in the following commit (3.7): c07cb01 sysv: drop lock/unlock super Signed-off-by: Lubomir Rintel --- fs/sysv/super.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/sysv/super.c b/fs/sysv/super.c index d0c6a00..eda1095 100644 --- a/fs/sysv/super.c +++ b/fs/sysv/super.c @@ -487,6 +487,7 @@ static int v7_fill_super(struct super_block *sb, void *data, int silent) sbi->s_sb = sb; sbi->s_block_base = 0; sbi->s_type = FSTYPE_V7; + mutex_init(>s_lock); sb->s_fs_info = sbi; sb_set_blocksize(sb, 512); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/1] Drivers: input: serio: New driver to support Hyper-V synthetic keyboard
Add a new driver to support synthetic keyboard. On the next generation
Hyper-V guest firmware, many legacy devices will not be emulated and this
driver will be required.
I would like to thank Vojtech Pavlik for helping me with the
details of the AT keyboard driver. I would also like to thank
Dan Carpenter and
Dmitry Torokhov for their detailed review of this
driver.
I have addressed all the comments of Dan and Dmitry in this version of
the patch
Signed-off-by: K. Y. Srinivasan
---
drivers/input/serio/Kconfig |7 +
drivers/input/serio/Makefile |1 +
drivers/input/serio/hyperv-keyboard.c | 404 +
3 files changed, 412 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/serio/hyperv-keyboard.c
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 1e691a3..f3996e7 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -267,4 +267,11 @@ config SERIO_OLPC_APSP
To compile this driver as a module, choose M here: the module will
be called olpc_apsp.
+config HYPERV_KEYBOARD
+ tristate "Microsoft Synthetic Keyboard driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable the Hyper-V Keyboard driver.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 12298b1..815d874 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_SERIO_ALTERA_PS2)+= altera_ps2.o
obj-$(CONFIG_SERIO_ARC_PS2)+= arc_ps2.o
obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
+obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o
diff --git a/drivers/input/serio/hyperv-keyboard.c
b/drivers/input/serio/hyperv-keyboard.c
new file mode 100644
index 000..c327a18
--- /dev/null
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -0,0 +1,404 @@
+/*
+ * Copyright (c) 2013, Microsoft Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Current version 1.0
+ *
+ */
+#define SYNTH_KBD_VERSION_MAJOR 1
+#define SYNTH_KBD_VERSION_MINOR0
+#define SYNTH_KBD_VERSION (SYNTH_KBD_VERSION_MINOR | \
+(SYNTH_KBD_VERSION_MAJOR << 16))
+
+
+/*
+ * Message types in the synthetic input protocol
+ */
+enum synth_kbd_msg_type {
+ SYNTH_KBD_PROTOCOL_REQUEST = 1,
+ SYNTH_KBD_PROTOCOL_RESPONSE = 2,
+ SYNTH_KBD_EVENT = 3,
+ SYNTH_KBD_LED_INDICATORS = 4,
+};
+
+/*
+ * Basic message structures.
+ */
+struct synth_kbd_msg_hdr {
+ u32 type;
+};
+
+struct synth_kbd_msg {
+ struct synth_kbd_msg_hdr header;
+ char data[1]; /* Enclosed message */
+};
+
+union synth_kbd_version {
+ struct {
+ u16 minor_version;
+ u16 major_version;
+ };
+ u32 version;
+};
+
+/*
+ * Protocol messages
+ */
+struct synth_kbd_protocol_request {
+ struct synth_kbd_msg_hdr header;
+ union synth_kbd_version version_requested;
+};
+
+#define PROTOCOL_ACCEPTED BIT(0)
+struct synth_kbd_protocol_response {
+ struct synth_kbd_msg_hdr header;
+ __le32 proto_status;
+};
+
+#define IS_UNICODE BIT(0)
+#define IS_BREAK BIT(1)
+#define IS_E0 BIT(2)
+#define IS_E1 BIT(3)
+struct synth_kbd_keystroke {
+ struct synth_kbd_msg_hdr header;
+ u16 make_code;
+ u16 reserved0;
+ __le32 info; /* Additional information */
+};
+
+
+#define HK_MAXIMUM_MESSAGE_SIZE 256
+
+#define KBD_VSC_SEND_RING_BUFFER_SIZE (10 * PAGE_SIZE)
+#define KBD_VSC_RECV_RING_BUFFER_SIZE (10 * PAGE_SIZE)
+
+#define XTKBD_EMUL0 0xe0
+#define XTKBD_EMUL1 0xe1
+#define XTKBD_RELEASE 0x80
+
+
+/*
+ * Represents a keyboard device
+ */
+struct hv_kbd_dev {
+ struct hv_device*device;
+ struct synth_kbd_protocol_request protocol_req;
+ struct synth_kbd_protocol_response protocol_resp;
+ /* Synchronize the request/response if needed */
+ struct completion wait_event;
+ struct serio*hv_serio;
+};
+
+
+static struct hv_kbd_dev *hv_kbd_alloc_device(struct hv_device *device)
+{
+ struct hv_kbd_dev *kbd_dev;
+ struct serio *hv_serio;
+
+ kbd_dev = kzalloc(sizeof(struct hv_kbd_dev), GFP_KERNEL);
+ if (!kbd_dev)
+ return NULL;
+ hv_serio = kzalloc(sizeof(struct serio),
Re: Build failures due to commit 416161db (btrfs: offline dedupe)
On Fri, Sep 13, 2013 at 03:33:34PM -0400, Chris Mason wrote:
> Mark, could you please send a patch for the whole-struct option until
> the unaligned put is upstreamed?
>
> -chris
Here you go. It's been lightly tested and needs review.
Thanks,
--Mark
--
Mark Fasheh
From: Mark Fasheh
[PATCH] btrfs: change extent-same to copy entire argument struct
btrfs_ioctl_file_extent_same() uses __put_user_unaligned() to copy some data
back to it's argument struct. Unfortunately, not all architectures provide
__put_user_unaligned(), so compiles break on them if btrfs is selected.
Instead, just copy the whole struct in / out at the start and end of
operations, respectively.
Signed-off-by: Mark Fasheh
---
fs/btrfs/ioctl.c | 76 +---
1 file changed, 45 insertions(+), 31 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 1a5b946..25d6920 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2696,9 +2696,9 @@ out_unlock:
static long btrfs_ioctl_file_extent_same(struct file *file,
void __user *argp)
{
- struct btrfs_ioctl_same_args *args = argp;
- struct btrfs_ioctl_same_args same;
- struct btrfs_ioctl_same_extent_info info;
+ struct btrfs_ioctl_same_args tmp;
+ struct btrfs_ioctl_same_args *same;
+ struct btrfs_ioctl_same_extent_info *info;
struct inode *src = file->f_dentry->d_inode;
struct file *dst_file = NULL;
struct inode *dst;
@@ -2706,6 +2706,7 @@ static long btrfs_ioctl_file_extent_same(struct file
*file,
u64 len;
int i;
int ret;
+ unsigned long size;
u64 bs = BTRFS_I(src)->root->fs_info->sb->s_blocksize;
bool is_admin = capable(CAP_SYS_ADMIN);
@@ -2716,15 +2717,30 @@ static long btrfs_ioctl_file_extent_same(struct file
*file,
if (ret)
return ret;
- if (copy_from_user(,
+ if (copy_from_user(,
(struct btrfs_ioctl_same_args __user *)argp,
- sizeof(same))) {
+ sizeof(tmp))) {
ret = -EFAULT;
goto out;
}
- off = same.logical_offset;
- len = same.length;
+ size = sizeof(tmp) +
+ tmp.dest_count * sizeof(struct btrfs_ioctl_same_extent_info);
+
+ same = kmalloc(size, GFP_NOFS);
+ if (!same) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ if (copy_from_user(same,
+ (struct btrfs_ioctl_same_args __user *)argp, size)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ off = same->logical_offset;
+ len = same->length;
/*
* Limit the total length we will dedupe for each operation.
@@ -2752,27 +2768,28 @@ static long btrfs_ioctl_file_extent_same(struct file
*file,
if (!S_ISREG(src->i_mode))
goto out;
- ret = 0;
- for (i = 0; i < same.dest_count; i++) {
- if (copy_from_user(, >info[i], sizeof(info))) {
- ret = -EFAULT;
- goto out;
- }
+ /* pre-format output fields to sane values */
+ for (i = 0; i < same->dest_count; i++) {
+ same->info[i].bytes_deduped = 0ULL;
+ same->info[i].status = 0;
+ }
- info.bytes_deduped = 0;
+ ret = 0;
+ for (i = 0; i < same->dest_count; i++) {
+ info = >info[i];
- dst_file = fget(info.fd);
+ dst_file = fget(info->fd);
if (!dst_file) {
- info.status = -EBADF;
+ info->status = -EBADF;
goto next;
}
if (!(is_admin || (dst_file->f_mode & FMODE_WRITE))) {
- info.status = -EINVAL;
+ info->status = -EINVAL;
goto next;
}
- info.status = -EXDEV;
+ info->status = -EXDEV;
if (file->f_path.mnt != dst_file->f_path.mnt)
goto next;
@@ -2781,32 +2798,29 @@ static long btrfs_ioctl_file_extent_same(struct file
*file,
goto next;
if (S_ISDIR(dst->i_mode)) {
- info.status = -EISDIR;
+ info->status = -EISDIR;
goto next;
}
if (!S_ISREG(dst->i_mode)) {
- info.status = -EACCES;
+ info->status = -EACCES;
goto next;
}
- info.status = btrfs_extent_same(src, off, len, dst,
- info.logical_offset);
- if (info.status == 0)
- info.bytes_deduped += len;
+
[PATCHv2 05/16] hwmon: lm75: expose to thermal fw via DT nodes
This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/hwmon/lm75.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
---
Guenter,
Here is a version without the warnings, as requested.
Eduardo
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..e42e361 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include "lm75.h"
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
/* Each client has this additional data */
struct lm75_data {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutexupdate_lock;
u8 orig_conf;
u8 resolution; /* In bits, between 9 and 12 */
@@ -90,22 +93,36 @@ static struct lm75_data *lm75_update_device(struct device
*dev);
/*---*/
+static inline long lm75_reg_to_mc(s16 temp, u8 resolution)
+{
+ return ((temp >> (16 - resolution)) * 1000) >> (resolution - 8);
+}
+
/* sysfs attributes for hwmon */
+static int lm75_read_temp(void *dev, long *temp)
+{
+ struct lm75_data *data = lm75_update_device(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ *temp = lm75_reg_to_mc(data->temp[0], data->resolution);
+
+ return 0;
+}
+
static ssize_t show_temp(struct device *dev, struct device_attribute *da,
char *buf)
{
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
struct lm75_data *data = lm75_update_device(dev);
- long temp;
if (IS_ERR(data))
return PTR_ERR(data);
- temp = ((data->temp[attr->index] >> (16 - data->resolution)) * 1000)
- >> (data->resolution - 8);
-
- return sprintf(buf, "%ld\n", temp);
+ return sprintf(buf, "%ld\n", lm75_reg_to_mc(data->temp[attr->index],
+ data->resolution));
}
static ssize_t set_temp(struct device *dev, struct device_attribute *da,
@@ -271,6 +288,13 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto exit_remove;
}
+ data->tz = thermal_zone_of_sensor_register(>dev,
+ 0,
+ >dev,
+ lm75_read_temp, NULL);
+ if (IS_ERR(data->tz))
+ data->tz = NULL;
+
dev_info(>dev, "%s: sensor '%s'\n",
dev_name(data->hwmon_dev), client->name);
@@ -285,6 +309,8 @@ static int lm75_remove(struct i2c_client *client)
{
struct lm75_data *data = i2c_get_clientdata(client);
+ /* thermal zone life cycle is not our responsibility */
+ thermal_zone_of_sensor_unregister(>dev, data->tz);
hwmon_device_unregister(data->hwmon_dev);
sysfs_remove_group(>dev.kobj, _group);
lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
--
1.8.2.1.342.gfa7285d
--
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/
[PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes
This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/hwmon/tmp102.c | 20
1 file changed, 20 insertions(+)
---
Guenter,
Here is a version without the warnings, as requested.
Eduardo
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..dc96598 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#defineDRIVER_NAME "tmp102"
@@ -50,6 +52,7 @@
struct tmp102 {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client
*client)
return tmp102;
}
+static int tmp102_read_temp(void *dev, long *temp)
+{
+ struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+ *temp = tmp102->temp[0];
+
+ return 0;
+}
+
static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,6 +216,12 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
+ tmp102->tz = thermal_zone_of_sensor_register(>dev, 0,
+>dev,
+tmp102_read_temp, NULL);
+ if (IS_ERR(tmp102->tz))
+ tmp102->tz = NULL;
+
dev_info(>dev, "initialized\n");
return 0;
@@ -220,6 +238,8 @@ static int tmp102_remove(struct i2c_client *client)
{
struct tmp102 *tmp102 = i2c_get_clientdata(client);
+ /* thermal zone life cycle is not our responsibility */
+ thermal_zone_of_sensor_unregister(>dev, tmp102->tz);
hwmon_device_unregister(tmp102->hwmon_dev);
sysfs_remove_group(>dev.kobj, _attr_group);
--
1.8.2.1.342.gfa7285d
--
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] clockevents: Sanitize ticks to nsec conversion
On 09/17/2013 11:15 PM, Thomas Gleixner wrote: > Marc Kleine-Budde pointed out, that commit 77cc982 "clocksource: use > clockevents_config_and_register() where possible" caused a regression > for some of the converted subarchs. > > The reason is, that the clockevents core code converts the minimal > hardware tick delta to a nanosecond value for core internal > usage. This conversion is affected by integer math rounding loss, so > the backwards conversion to hardware ticks will likely result in a > value which is less than the configured hardware limitation. The > affected subarchs used their own workaround (SIGH!) which got lost in > the conversion. > > Now instead of fixing the underlying core code problem, Marcs patch > tried to work around the core code issue by increasing the minimal > tick delta at clockevents registration time so the resulting limit in > the core code backwards conversion did not violate the hardware > limits. More SIGH! It was not easy getting your attention with this problem :) Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 06/16] hwmon: tmp102: expose to thermal fw via DT nodes
On 15-09-2013 19:33, Guenter Roeck wrote:
> On 09/15/2013 03:02 PM, Eduardo Valentin wrote:
>> This patch adds to tmp102 temperature sensor the possibility
>> to expose itself as thermal zone device, registered on the
>> thermal framework.
>>
>> The thermal zone is built only if a device tree node
>> describing a thermal zone for this sensor is present
>> inside the tmp102 DT node. Otherwise, the driver behavior
>> will be the same.
>>
>> Cc: Jean Delvare
>> Cc: Guenter Roeck
>> Cc: lm-sens...@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin
>> ---
>> drivers/hwmon/tmp102.c | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..e432444 100644
>> --- a/drivers/hwmon/tmp102.c
>> +++ b/drivers/hwmon/tmp102.c
>> @@ -27,6 +27,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #defineDRIVER_NAME "tmp102"
>>
>> @@ -50,6 +52,7 @@
>>
>> struct tmp102 {
>> struct device *hwmon_dev;
>> +struct thermal_zone_device *tz;
>> struct mutex lock;
>> u16 config_orig;
>> unsigned long last_update;
>> @@ -93,6 +96,19 @@ static struct tmp102 *tmp102_update_device(struct
>> i2c_client *client)
>> return tmp102;
>> }
>>
>> +static int tmp102_read_temp(void *dev, long *temp)
>> +{
>> +struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
>> +
>> +if (tmp102->temp[0] < 0)
>> +dev_warn(tmp102->hwmon_dev,
>> + "operating in negative temp: %d\n", tmp102->temp[0]);
>> +
>
> Please drop this warning.
>
Done for both drivers.
> Guenter
>
>> +*temp = tmp102->temp[0];
>> +
>> +return 0;
>> +}
>> +
>> static ssize_t tmp102_show_temp(struct device *dev,
>> struct device_attribute *attr,
>> char *buf)
>> @@ -204,6 +220,16 @@ static int tmp102_probe(struct i2c_client *client,
>> goto fail_remove_sysfs;
>> }
>>
>> +tmp102->tz = thermal_zone_of_sensor_register(>dev, 0,
>> + >dev,
>> + tmp102_read_temp, NULL);
>> +if (IS_ERR(tmp102->tz)) {
>> +dev_warn(>dev,
>> + "Could not parse thermal data in device tree: %ld\n",
>> + PTR_ERR(tmp102->tz));
>
> Please drop this warning. You already create error messages in
> thermal_zone_of_sensor_register(). That should be sufficient.
> The same applies to the lm75 patch.
OK. Done for both.
>
> As a side note, I would suggest to provide devm_ functions for
> registration.
> We are introducing those for hwmon registration, which enables us to remove
> most _remove functions. It would be great if we can keep it that way.
>
Right. This side note is taken. Actually this is on my todo list for
quite a while. But I believe this should not block this series, should
it? I will be probably cleaning the thermal framework code after this
current work is accepted at least.
> On a higher level, I don't think it is a good idea to make thermal zones
> and thermal zone data mandatory. Many systems may neither need nor want it.
>
Well, I agree with you. Did you see something hard required in the patch
I sent. I made it so that it could continue the driver probe without
thermal zones, as you requested.
I will repost both patches in reply to our thread.
Eduardo
> Guenter
>
>> +tmp102->tz = NULL;
>> +}
>> +
>> dev_info(>dev, "initialized\n");
>>
>> return 0;
>> @@ -220,6 +246,8 @@ static int tmp102_remove(struct i2c_client *client)
>> {
>> struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>
>> +/* thermal zone life cycle is not our responsibility */
>> +thermal_zone_of_sensor_unregister(>dev, tmp102->tz);
>> hwmon_device_unregister(tmp102->hwmon_dev);
>> sysfs_remove_group(>dev.kobj, _attr_group);
>>
>>
>
>
>
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
[PATCH] fbcon: fix deadlock in fbcon_generic_blank()
Do not lock fb_info when calling sending the FB_EVENT_CONBLANK event. In fbmem.c, the semantics are that we acquire the lock_fb_info first, and then console_lock. However when fbcon.c fbcon_generic_blank() is called, the console lock could already be held. Locking fb_info can thus cause a deadlock. fbmem.c sends the FB_EVENT_BLANK without locking lock_fb_info first, so this change introduces similar behaviour. Signed-off-by: John Tapsell --- drivers/video/console/fbcon.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 6b4fb5c..8546441 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -2333,13 +2333,9 @@ static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info, vc->vc_video_erase_char = oldc; } - -if (!lock_fb_info(info)) -return; event.info = info; event.data = fb_notifier_call_chain(FB_EVENT_CONBLANK, ); -unlock_fb_info(info); } static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
