Re: [Cocci] [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
> The error return value of platform_get_irq seems to often get dropped. How do you think about any more fine-tuning here? Commit message: * … of the platform_get_irq() function seems to get dropped too often. * Why do you concentrate on a single function name? Do you plan to extend this source code analysis approach? > +@script:python r_report depends on report@ > +j0 << r.j0; > +j1 << r.j1; > +@@ > + > +msg = "Propagate return value of platform_get_irq around line %s." % > (j1[0].line) Are there more unchecked return values which are interesting for further considerations? https://cwe.mitre.org/data/definitions/252.html Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote: > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote: > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote: > > > Hi all, > > > > > > This is v6 of the series. > > > > > > Link for v1: https://lkml.org/lkml/2015/8/27/798 > > > Link for v2: https://lkml.org/lkml/2015/9/16/527 > > > Link for v3: https://lkml.org/lkml/2015/10/12/368 > > > Link for v4: https://lkml.org/lkml/2015/10/14/670 > > > Link for v5: https://lkml.org/lkml/2015/10/26/141 > > > > > > > > > Changes since v5: > > > > > > * rebase on the next branch of powerpc. > > > > > > * pull two fix and one testcase patches out, which are already > > > sent separately > > > > > > * some clean up or code format fixing. > > > > > > > > > Paul, Peter and Will, thank you for your comments and suggestions in the > > > review > > > of previous versions. From this version on, This series is against the > > > next > > > branch of powerpc tree, because most of the code touch arch/powerpc/*. > > > > > > Sorry if we already discussed this, but did we decide how we were going to > > merge this? There's the one patch to generic code and then three powerpc > > patches. > > > > It'd make most sense for it to go via powerpc I think. Given that the > > change to > > generic code is relatively trivial I'll plan to merge this unless someone > > objects. > > > > Also it is pretty late in the -next cycle for something like this. But > > AFAICS > > there are no users of these "atomic*relaxed" variants yet other than arm64 > > code > > and qspinlocks, neither of which are used on powerpc. So adding them should > > be > > pretty harmless. > > > > There is one thing we should be aware of, that is the bug: > > http://lkml.kernel.org/r/5669d5f2.5050...@caviumnetworks.com > > which though has been fixed by: > > http://lkml.kernel.org/r/20151217160549.gh6...@twins.programming.kicks-ass.net > > but the fix is not in powerpc/next right now. As this patchset makes > atomic_xchg_acquire a real ACQUIRE, so we will also trigger that bug if > this series gets merged in the next branch of powerpc tree, though > that's not the problem of this patchset. > > Not sure whether this is a problem for your maintence, but just think > it's better to make you aware of this ;-) Yes that's pretty important thank you :) It's not so much that bug that's important, but the fact that I completely forget about the acquire/release implementations. Those are used already in mainline and so we don't want to add implementations this late in the cycle without wider testing. So I'll have to push this series until 4.6 so it can get some time in -next. Sorry! cheers -- 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: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks
On Sat, Dec 26, 2015 at 6:16 PM, Andy Lutomirski wrote:
>>> We could make one of them 31-bits (since even an "allyesconfig" kernel
>>> is still much smaller than a gigabyte) to free a bit for a flag. But there
>>> are those external tools to pre-sort exception tables that would all
>>> need to be fixed too.
>
> Wait, why? The external tools sort by source address, and we'd
> squeeze the flag into the target address, no?
I was thinking that we'd need to recompute the fixup when we move
the entry to its new sorted location. So that:
ex_fixup_addr(const struct exception_table_entry *x)
{
return (unsigned long)>fixup + x->fixup;
}
will get the right value. Maybe this would still work out
if the fixup is a 31-bit value plus a flag, but the external
tool thinks it is a 32-bit value? I'd have to ponder that.
-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 v2] staging: lustre: fix lock imbalance
nrs_resource_put_safe() might hold a lock one one struct
while operating on the other.
There are 2 levels of structures.
Use nrs_policy_put(), which has locking baked in.
sparse gives the following warning:
drivers/staging/lustre//lustre/ptlrpc/nrs.c:498:39:
warning: context imbalance in 'nrs_resource_put_safe' -
different lock contexts for basic block
Signed-off-by: Joshua Clayton
---
changed for v2:
- remove unused nrs variable
drivers/staging/lustre/lustre/ptlrpc/nrs.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
index 7044e1f..57acf8c 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
@@ -482,7 +482,6 @@ static void nrs_resource_get_safe(struct ptlrpc_nrs *nrs,
static void nrs_resource_put_safe(struct ptlrpc_nrs_resource **resp)
{
struct ptlrpc_nrs_policy *pols[NRS_RES_MAX];
- struct ptlrpc_nrs *nrs = NULL;
int i;
for (i = 0; i < NRS_RES_MAX; i++) {
@@ -496,18 +495,9 @@ static void nrs_resource_put_safe(struct
ptlrpc_nrs_resource **resp)
}
for (i = 0; i < NRS_RES_MAX; i++) {
- if (pols[i] == NULL)
- continue;
-
- if (nrs == NULL) {
- nrs = pols[i]->pol_nrs;
- spin_lock(>nrs_lock);
- }
- nrs_policy_put_locked(pols[i]);
+ if (pols[i])
+ nrs_policy_put(pols[i]);
}
-
- if (nrs != NULL)
- spin_unlock(>nrs_lock);
}
/**
--
2.6.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 RESEND v2 1/1] fix a dead loop when in heavy low memory
> > > > Signed-off-by: Figo Zhang > > As you ignored my instructions to you, I'm going to just ignore this patch, > sorry. Now discarded. > I am no at intel kernel group (SSG OTC), I am at CCG CCE. I will involve the intel open source guys if they like to help. Hi fengguang: Would you like to help review or involve the related intel guys? This issue can reproduce on android devices, I think This current upstream code maybe some problem. Your technical comments are welcome. Best, Figo -- 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] mm: fix noisy sparse warning in LIBCFS_ALLOC_PRE()
running sparse on drivers/staging/lustre results in dozens of warnings:
include/linux/gfp.h:281:41: warning:
odd constant _Bool cast (40 becomes 1)
Use "!!" to explicitly convert to bool and get rid of the warning.
Signed-off-by: Joshua Clayton
---
On Sunday, December 27, 2015 05:41:17 AM Al Viro wrote:
> On Sat, Dec 26, 2015 at 09:12:42PM -0800, Joshua Clayton wrote:
> > running sparse on drivers/staging/lustre results in dozens of warnings:
> > include/linux/gfp.h:281:41: warning:
> > odd constant _Bool cast (40 becomes 1)
> >
> > Use "!!" to explicitly convert the result to bool range.
>
> ... and the cast to bool is left in order to...?
>
> > - return (bool __force)(gfp_flags & __GFP_DIRECT_RECLAIM);
> > + return (bool __force)!!(gfp_flags & __GFP_DIRECT_RECLAIM);
to embarrass me, I suppose. :(
I didn't think about the redundancy of the cast.
Lets try that again.
include/linux/gfp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 91f74e7..28ad5f6 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -278,7 +278,7 @@ static inline int gfpflags_to_migratetype(const gfp_t
gfp_flags)
static inline bool gfpflags_allow_blocking(const gfp_t gfp_flags)
{
- return (bool __force)(gfp_flags & __GFP_DIRECT_RECLAIM);
+ return !!(gfp_flags & __GFP_DIRECT_RECLAIM);
}
#ifdef CONFIG_HIGHMEM
--
2.6.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] coccinelle: api: check for propagation of error from platform_get_irq
>Well, looking again, the patch should be good. I just thought its goal was > to fix the code as well... I could do that for the irq < 0 case, but I think that in that case, kbuild will only run the patch version, and the <= cases will not be reported on. I don't have a general fix for the <= 0. Is it even correct to have < in some cases and <= in others? julia -- 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 0/3] IDE-ACPI: Fine-tuning for a function
On Sat, 26 Dec 2015, Joe Perches wrote: > On Sat, 2015-12-26 at 13:12 -0500, David Miller wrote: > > IDE is in deep freeze maintainence mode. > > > > Therefore patches that perform simplications and cleanups will > > not be accepted. > > Maybe there should be something like a README > in drivers/ide that says that. > > Maybe the MAINTAINERS entry for "IDE SUBSYSTEM" > should be something like: > > S:Frozen - critical fixes only This could be a good idea. Sometimes I hold off on sending patches for things becuse I have the impression that the subsystem doesn't want minor fixes, but I could be wrong, and if one could have a deterministic way to know, it could be better for everyone. julia -- 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] mm: fix noisy sparse warning in LIBCFS_ALLOC_PRE()
On Sat, Dec 26, 2015 at 09:12:42PM -0800, Joshua Clayton wrote: > running sparse on drivers/staging/lustre results in dozens of warnings: > include/linux/gfp.h:281:41: warning: > odd constant _Bool cast (40 becomes 1) > > Use "!!" to explicitly convert the result to bool range. ... and the cast to bool is left in order to...? > - return (bool __force)(gfp_flags & __GFP_DIRECT_RECLAIM); > + return (bool __force)!!(gfp_flags & __GFP_DIRECT_RECLAIM); -- 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] staging: lustre: fix lock imbalance
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
Hi Joshua,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.4-rc6 next-20151223]
url:
https://github.com/0day-ci/linux/commits/Joshua-Clayton/staging-lustre-fix-lock-imbalance/20151227-131137
config: x86_64-allyesconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/staging/lustre/lustre/ptlrpc/nrs.c: In function
'nrs_resource_put_safe':
>> drivers/staging/lustre/lustre/ptlrpc/nrs.c:485:21: warning: unused variable
>> 'nrs' [-Wunused-variable]
struct ptlrpc_nrs *nrs = NULL;
^
vim +/nrs +485 drivers/staging/lustre/lustre/ptlrpc/nrs.c
d7e09d039 Peng Tao 2013-05-02 469 nrs_policy_put(primary);
d7e09d039 Peng Tao 2013-05-02 470 }
d7e09d039 Peng Tao 2013-05-02 471 }
d7e09d039 Peng Tao 2013-05-02 472
d7e09d039 Peng Tao 2013-05-02 473 /**
d7e09d039 Peng Tao 2013-05-02 474 * Releases references to resource
hierarchies and policies, because they are no
d7e09d039 Peng Tao 2013-05-02 475 * longer required; used when request
handling has been completed, or the
d7e09d039 Peng Tao 2013-05-02 476 * request is moving to the high priority
NRS head.
d7e09d039 Peng Tao 2013-05-02 477 *
d7e09d039 Peng Tao 2013-05-02 478 * \param resp the resource hierarchy
that is being released
d7e09d039 Peng Tao 2013-05-02 479 *
d7e09d039 Peng Tao 2013-05-02 480 * \see ptlrpc_nrs_req_finalize()
d7e09d039 Peng Tao 2013-05-02 481 */
d7e09d039 Peng Tao 2013-05-02 482 static void nrs_resource_put_safe(struct
ptlrpc_nrs_resource **resp)
d7e09d039 Peng Tao 2013-05-02 483 {
d7e09d039 Peng Tao 2013-05-02 484 struct ptlrpc_nrs_policy
*pols[NRS_RES_MAX];
d7e09d039 Peng Tao 2013-05-02 @485 struct ptlrpc_nrs *nrs = NULL;
d7e09d039 Peng Tao 2013-05-02 486 int i;
d7e09d039 Peng Tao 2013-05-02 487
d7e09d039 Peng Tao 2013-05-02 488 for (i = 0; i < NRS_RES_MAX; i++) {
d7e09d039 Peng Tao 2013-05-02 489 if (resp[i] != NULL) {
d7e09d039 Peng Tao 2013-05-02 490 pols[i] =
resp[i]->res_policy;
d7e09d039 Peng Tao 2013-05-02 491
nrs_resource_put(resp[i]);
d7e09d039 Peng Tao 2013-05-02 492 resp[i] = NULL;
d7e09d039 Peng Tao 2013-05-02 493 } else {
:: The code at line 485 was first introduced by commit
:: d7e09d0397e84eefbabfd9cb353221f3c6448d83 staging: add Lustre file system
client support
:: TO: Peng Tao
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH] mm: fix noisy sparse warning in LIBCFS_ALLOC_PRE()
running sparse on drivers/staging/lustre results in dozens of warnings:
include/linux/gfp.h:281:41: warning:
odd constant _Bool cast (40 becomes 1)
Use "!!" to explicitly convert the result to bool range.
---
include/linux/gfp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 91f74e7..6e58a8f 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -278,7 +278,7 @@ static inline int gfpflags_to_migratetype(const gfp_t
gfp_flags)
static inline bool gfpflags_allow_blocking(const gfp_t gfp_flags)
{
- return (bool __force)(gfp_flags & __GFP_DIRECT_RECLAIM);
+ return (bool __force)!!(gfp_flags & __GFP_DIRECT_RECLAIM);
}
#ifdef CONFIG_HIGHMEM
--
2.6.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] staging: lustre: fix lock imbalance
nrs_resource_put_safe() might hold a lock one one struct
while operating on the other.
There are 2 levels of structures.
Use nrs_policy_put(), which has locking baked in.
sparse gives the following warning:
drivers/staging/lustre//lustre/ptlrpc/nrs.c:498:39:
warning: context imbalance in 'nrs_resource_put_safe' -
different lock contexts for basic block
---
drivers/staging/lustre/lustre/ptlrpc/nrs.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
index 7044e1f..9028b12 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
@@ -496,18 +496,9 @@ static void nrs_resource_put_safe(struct
ptlrpc_nrs_resource **resp)
}
for (i = 0; i < NRS_RES_MAX; i++) {
- if (pols[i] == NULL)
- continue;
-
- if (nrs == NULL) {
- nrs = pols[i]->pol_nrs;
- spin_lock(>nrs_lock);
- }
- nrs_policy_put_locked(pols[i]);
+ if (pols[i])
+ nrs_policy_put(pols[i]);
}
-
- if (nrs != NULL)
- spin_unlock(>nrs_lock);
}
/**
--
2.6.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 RESEND v2 1/1] fix a dead loop when in heavy low memory
On Sun, Dec 27, 2015 at 05:14:51PM +0800, Figo Zhang wrote:
> Android System UI hang when run heavy monkey stress test.
>
> V2: add more detail about how to re-produce this issue, the
> important is install more than 100 apps/games.
>
> Re-produce step:
> Run this monkey stress test script with more than 100
> apps/games installed:
>
> adb shell "monkey --ignore-crashes --ignore-timeouts
> --kill-process-after-error --ignore-security-exceptions
> --throttle 200 -v 2000"
>
> kernel log:
> [ 1526.272125] lowmem_scan start: 128, 213da, ofree -9849 34419, ma 529
> [ 1526.272260] lowmemorykiller: select 'dTi-lm' (27289), adj 647, size 10630,
> to kill
> [ 1526.272299] lowmem_d_timeout=4296194081
> [ 1526.272303] Killing 'dTi-lm' (27289), adj 647,
> [ 1526.272303]to free 42520kB on behalf of 'servicemanager' (2365) because
> [ 1526.272303]cache 137676kB is below limit 221184kB for oom_score_adj 529
> [ 1526.272303]Free memory is -39396kB above reserved
> [ 1526.272304] lowmem_scan end: 128, 213da, return 10630
> [ 1526.272710] lowmem_scan start: 128, 213da, ofree -9849 34373, ma 529
> [ 1526.272832] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193081,
> 4296194081
> [ 1526.274450] lowmem_scan start: 128, 280da, ofree -9601 34327, ma 529
> [ 1526.274695] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193083,
> 4296194081
> [ 1526.282292] lowmem_scan start: 128, 213da, ofree -9703 34327, ma 529
> [ 1526.282727] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193090,
> 4296194081
> [ 1526.316888] lowmem_scan start: 128, 213da, ofree -9766 34465, ma 529
> [ 1526.317019] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
> 4296194081
> [ 1526.319311] lowmem_scan start: 128, 213da, ofree -9856 34419, ma 529
> [ 1526.319442] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
> 4296194081
> [ 1526.322026] lowmem_scan start: 128, 280da, ofree -9841 34327, ma 529
> [ 1526.360831] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193166,
> 4296194081
> [ 1526.532233] lowmem_scan start: 128, 213da, ofree -9846 34511, ma 529
> [ 1526.644046] lowmem_scan start: 128, 213da, ofree -9785 34235, ma 529
> [ 1527.437578] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194246,
> 4296195109
> [ 1527.442559] lowmem_scan start: 128, 213da, ofree -9850 41884, ma 529
> [ 1527.459540] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194268,
> 4296195109
> [ 1527.500352] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194309,
> 4296195109
>
> when this happened, the android system UI will hang, no process can be
> select to kill.
>
> i found the the value of "lowmem_deathpending_timeout" will be modified
> strangely, like in last killing, the value is 4296194081, but why not it
> had changed to 4296195109? so it will cause the deadloop in low memory
> state which will cause the android system UI hang, because no process will
> be kill.
>
> commit e5d7965f88a3 ("staging: android: lowmemorykiller: Don't wait more
> than one second for a process to die") said wait 1 seconds, i think it no
> need to wait 1 second, because we don't select the process with
> "TIF_MEMDIE" to kill.
>
> Signed-off-by: Figo Zhang
As you ignored my instructions to you, I'm going to just ignore this
patch, sorry. Now discarded.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks
On Sat, Dec 26, 2015 at 6:08 PM, Tony Luck wrote:
> On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski wrote:
>> On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote:
>>> Andy, why is that? It makes the exception handling much simpler this way...
>>>
>>
>> I like the idea of moving more logic into C, but I don't like
>> splitting the logic across files and adding nasty special cases like
>> this.
>>
>> But what if we generalized it? An extable entry gives a fault IP and
>> a landing pad IP. Surely we can squeeze a flag bit in there.
>
> The clever squeezers have already been here. Instead of a pair
> of 64-bit values for fault_ip and fixup_ip they managed with a pair
> of 32-bit values that are each the relative offset of the desired address
> from the table location itself.
>
> We could make one of them 31-bits (since even an "allyesconfig" kernel
> is still much smaller than a gigabyte) to free a bit for a flag. But there
> are those external tools to pre-sort exception tables that would all
> need to be fixed too.
>
> Or we could direct the new fixups into a .fixup2 ELF section and put
> begin/end labels around that ... so we could check the address of the
> fixup to see whether it is a legacy or new format entry.
>
Either of those sounds good to me.
>> set the bit, you get an extended extable entry. Instead of storing a
>> landing pad, it stores a pointer to a handler descriptor:
>>
>> struct extable_handler {
>> bool (*handler)(struct pt_regs *, struct extable_handler *, ...):
>> };
>>
>> handler returns true if it handled the error and false if it didn't.
>
> It may be had to call that from the machine check handler ... the
> beauty of just patching the IP and returning from the handler was
> that it got us out of machine check context.
Your handler will need to know that it's in machine check context :)
In most cases (e.g. yours), the handler should just modify regs and
return.
>
>> The "..." encodes the fault number, error code, cr2, etc. Maybe it
>> would be "unsigned long exception, const struct extable_info *info"
>> where extable_info contains a union? I really wish C would grow up
>> and learn about union types.
>
> All this is made more difficult because the h/w doesn't give us
> all the things we might want to know (e.g. the virtual address).
> We just have a physical address (which may be missing some
> low order bits).
True. I'm afraid that nothing I suggest can possibly help you there.
Anyhow, this could be a decent signature:
bool (*handler)(struct pt_regs *, struct extable_handler *, unsigned
int exception, unsigned long error_code, unsigned long extra):
If exception is X86_TRAP_PF, then extra is CR2. If exception is
X86_TRAP_MC, then extra is however much of the PA you know.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks
On Sat, Dec 26, 2015 at 6:15 PM, Andy Lutomirski wrote: > On Sat, Dec 26, 2015 at 6:08 PM, Tony Luck wrote: >> On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski wrote: >>> On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote: Andy, why is that? It makes the exception handling much simpler this way... >>> >>> I like the idea of moving more logic into C, but I don't like >>> splitting the logic across files and adding nasty special cases like >>> this. >>> >>> But what if we generalized it? An extable entry gives a fault IP and >>> a landing pad IP. Surely we can squeeze a flag bit in there. >> >> The clever squeezers have already been here. Instead of a pair >> of 64-bit values for fault_ip and fixup_ip they managed with a pair >> of 32-bit values that are each the relative offset of the desired address >> from the table location itself. >> >> We could make one of them 31-bits (since even an "allyesconfig" kernel >> is still much smaller than a gigabyte) to free a bit for a flag. But there >> are those external tools to pre-sort exception tables that would all >> need to be fixed too. Wait, why? The external tools sort by source address, and we'd squeeze the flag into the target address, no? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 14/16] x86, nvdimm, kexec: Use walk_iomem_res_desc() for iomem search
On 12/26/15 at 05:31pm, Toshi Kani wrote: > + cc: kexec list > > On 12/26/2015 3:38 AM, Borislav Petkov wrote: > >On Fri, Dec 25, 2015 at 03:09:23PM -0700, Toshi Kani wrote: > >>Change to call walk_iomem_res_desc() for searching resource entries > >>with the following names: > >> "ACPI Tables" > >> "ACPI Non-volatile Storage" > >> "Persistent Memory (legacy)" > >> "Crash kernel" > >> > >>Note, the caller of walk_iomem_res() with "GART" is left unchanged > >>because this entry may be initialized by out-of-tree drivers, which > >>do not have 'desc' set to IORES_DESC_GART. > > > >There's this out-of-tree bogus argument again. :\ > > > >Why do we care about out-of-tree drivers? > > > >You can just as well fix the "GART" case too and kill walk_iomem_res() > >altogether... > > Right, but I do not see any "GART" case in the upstream code, so I > cannot change it... Hi, Toshi. You can refer the below link that you may get a clue about GART. This is the fisrt time kexec-tools tried to support to ignore GART region in 2nd kernel. http://lists.infradead.org/pipermail/kexec/2008-December/003096.html Thanks Minfei -- 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: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks
On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski wrote:
> On Dec 26, 2015 6:33 PM, "Borislav Petkov" wrote:
>> Andy, why is that? It makes the exception handling much simpler this way...
>>
>
> I like the idea of moving more logic into C, but I don't like
> splitting the logic across files and adding nasty special cases like
> this.
>
> But what if we generalized it? An extable entry gives a fault IP and
> a landing pad IP. Surely we can squeeze a flag bit in there.
The clever squeezers have already been here. Instead of a pair
of 64-bit values for fault_ip and fixup_ip they managed with a pair
of 32-bit values that are each the relative offset of the desired address
from the table location itself.
We could make one of them 31-bits (since even an "allyesconfig" kernel
is still much smaller than a gigabyte) to free a bit for a flag. But there
are those external tools to pre-sort exception tables that would all
need to be fixed too.
Or we could direct the new fixups into a .fixup2 ELF section and put
begin/end labels around that ... so we could check the address of the
fixup to see whether it is a legacy or new format entry.
> set the bit, you get an extended extable entry. Instead of storing a
> landing pad, it stores a pointer to a handler descriptor:
>
> struct extable_handler {
> bool (*handler)(struct pt_regs *, struct extable_handler *, ...):
> };
>
> handler returns true if it handled the error and false if it didn't.
It may be had to call that from the machine check handler ... the
beauty of just patching the IP and returning from the handler was
that it got us out of machine check context.
> The "..." encodes the fault number, error code, cr2, etc. Maybe it
> would be "unsigned long exception, const struct extable_info *info"
> where extable_info contains a union? I really wish C would grow up
> and learn about union types.
All this is made more difficult because the h/w doesn't give us
all the things we might want to know (e.g. the virtual address).
We just have a physical address (which may be missing some
low order bits).
-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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 1:51 PM, Serge E. Hallyn
wrote:
> On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote:
>> ptrace_has_cap() checks whether the current process should be
>> treated as having a certain capability for ptrace checks
>> against another process. Until now, this was equivalent to
>> has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
>>
>> However, if a root-owned process wants to enter a user
>> namespace for some reason without knowing who owns it and
>> therefore can't change to the namespace owner's uid and gid
>> before entering, as soon as it has entered the namespace,
>> the namespace owner can attach to it via ptrace and thereby
>> gain access to its uid and gid.
>>
>> While it is possible for the entering process to switch to
>> the uid of a claimed namespace owner before entering,
>> causing the attempt to enter to fail if the claimed uid is
>> wrong, this doesn't solve the problem of determining an
>> appropriate gid.
>>
>> With this change, the entering process can first enter the
>> namespace and then safely inspect the namespace's
>> properties, e.g. through /proc/self/{uid_map,gid_map},
>> assuming that the namespace owner doesn't have access to
>> uid 0.
>>
>> Changed in v2: The caller needs to be capable in the
>> namespace into which tcred's uids/gids can be mapped.
>>
>> Signed-off-by: Jann Horn
>
> Acked-by: Serge Hallyn
Acked-by: Andy Lutomirski
Who's going to apply this? Linus? Eric?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 1/1] fix a dead loop when in heavy low memory
Android System UI hang when run heavy monkey stress test.
V2: add more detail about how to re-produce this issue, the
important is install more than 100 apps/games.
Re-produce step:
Run this monkey stress test script with more than 100
apps/games installed:
adb shell "monkey --ignore-crashes --ignore-timeouts
--kill-process-after-error --ignore-security-exceptions
--throttle 200 -v 2000"
kernel log:
[ 1526.272125] lowmem_scan start: 128, 213da, ofree -9849 34419, ma 529
[ 1526.272260] lowmemorykiller: select 'dTi-lm' (27289), adj 647, size 10630,
to kill
[ 1526.272299] lowmem_d_timeout=4296194081
[ 1526.272303] Killing 'dTi-lm' (27289), adj 647,
[ 1526.272303]to free 42520kB on behalf of 'servicemanager' (2365) because
[ 1526.272303]cache 137676kB is below limit 221184kB for oom_score_adj 529
[ 1526.272303]Free memory is -39396kB above reserved
[ 1526.272304] lowmem_scan end: 128, 213da, return 10630
[ 1526.272710] lowmem_scan start: 128, 213da, ofree -9849 34373, ma 529
[ 1526.272832] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193081,
4296194081
[ 1526.274450] lowmem_scan start: 128, 280da, ofree -9601 34327, ma 529
[ 1526.274695] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193083,
4296194081
[ 1526.282292] lowmem_scan start: 128, 213da, ofree -9703 34327, ma 529
[ 1526.282727] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193090,
4296194081
[ 1526.316888] lowmem_scan start: 128, 213da, ofree -9766 34465, ma 529
[ 1526.317019] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
4296194081
[ 1526.319311] lowmem_scan start: 128, 213da, ofree -9856 34419, ma 529
[ 1526.319442] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
4296194081
[ 1526.322026] lowmem_scan start: 128, 280da, ofree -9841 34327, ma 529
[ 1526.360831] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193166,
4296194081
[ 1526.532233] lowmem_scan start: 128, 213da, ofree -9846 34511, ma 529
[ 1526.644046] lowmem_scan start: 128, 213da, ofree -9785 34235, ma 529
[ 1527.437578] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194246,
4296195109
[ 1527.442559] lowmem_scan start: 128, 213da, ofree -9850 41884, ma 529
[ 1527.459540] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194268,
4296195109
[ 1527.500352] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194309,
4296195109
when this happened, the android system UI will hang, no process can be
select to kill.
i found the the value of "lowmem_deathpending_timeout" will be modified
strangely, like in last killing, the value is 4296194081, but why not it
had changed to 4296195109? so it will cause the deadloop in low memory
state which will cause the android system UI hang, because no process will
be kill.
commit e5d7965f88a3 ("staging: android: lowmemorykiller: Don't wait more
than one second for a process to die") said wait 1 seconds, i think it no
need to wait 1 second, because we don't select the process with
"TIF_MEMDIE" to kill.
Signed-off-by: Figo Zhang
---
drivers/staging/android/lowmemorykiller.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index e679d84..13c7182 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -59,8 +59,6 @@ static int lowmem_minfree[6] = {
};
static int lowmem_minfree_size = 4;
-static unsigned long lowmem_deathpending_timeout;
-
#define lowmem_print(level, x...) \
do {\
if (lowmem_debug_level >= (level)) \
@@ -128,11 +126,9 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
if (!p)
continue;
- if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
- time_before_eq(jiffies, lowmem_deathpending_timeout)) {
+ if (test_tsk_thread_flag(p, TIF_MEMDIE)) {
task_unlock(p);
- rcu_read_unlock();
- return 0;
+ continue;
}
oom_score_adj = p->signal->oom_score_adj;
if (oom_score_adj < min_score_adj) {
@@ -170,7 +166,6 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
selected->pid, selected->comm,
selected_oom_score_adj, selected_tasksize);
- lowmem_deathpending_timeout = jiffies + HZ;
rem += selected_tasksize;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: gdm72xx: Code cleanups
On Fri, Dec 11, 2015 at 02:39:11AM -0500, Sanidhya Solanki wrote: > >From c07c57f3e045865b0acae498c631189f24aeda0b Mon Sep 17 00:00:00 2001 > From: Sanidhya Solanki > Date: Thu, 10 Dec 2015 21:13:10 -0500 > Subject: [PATCH] staging: gdm72xx: Code cleanups What is all of this in here for? > Code cleanups as per the TODO file. Please be very specific as to what you did. And only do one type of thing per patch. Please fix up and resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] extcon next for 4.5
On Thu, Dec 24, 2015 at 09:58:27AM +0900, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-next pull request for v4.5. I add detailed description of > this pull request on below. Please pull extcon with following updates. > > Best Regards, > Chanwoo Choi > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-4.5 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/28] phy: for 4.5 merge window
On Tue, Dec 22, 2015 at 04:08:33PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the pull request for 4.5 merge window below. This should be > my final pull request for 2015 unless you want me to change > something ;-) > > It adds two new PHY drivers, deprecates phy-omap-control driver (it > was in my TO-DO for sometime), and other miscellaneous phy driver > improvements and fixes. > > Let me know if you want me to modify something. > > Merry Christmas and Happy Newyear! > > Cheers > Kishon > > The following changes since commit 708744628ba96ed4dfcac74a985eb66ad551f164: > > phy: core: Get a refcount to phy in devm_of_phy_get_by_index() (2015-12-07 > 18:44:02 +0530) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > tags/phy-for-4.5 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] USB patches for v4.5
On Wed, Dec 23, 2015 at 10:45:56AM -0600, Felipe Balbi wrote: > Hi Greg, > > Here's the large usb gadget pull request for v4.5. Please consider > merging it to your usb-next branch. We have a total 97 non-merge commits > this time, so a substantial amount of code. Here's a dirstat to show you > where most of changes are: > > $ git diff --dirstat 9f9499ae8e64 > 22.5% drivers/usb/dwc2/ >8.7% drivers/usb/dwc3/ >9.5% drivers/usb/gadget/function/ > 35.9% drivers/usb/gadget/udc/ >6.2% drivers/usb/phy/ >5.0% drivers/usb/renesas_usbhs/ >7.2% drivers/usb/ > > The following changes since commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89: > > Linux 4.4-rc5 (2015-12-13 17:42:58 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.5 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 1/1] fix a dead loop when in heavy low memory
On Sun, Dec 27, 2015 at 04:34:56PM +0800, Figo.zhang wrote: > From: Figo This doesn't match your signed-off-by name :( > Signed-off-by: Figo.zhang I doubt that you have a '.' in your name :( Again, please consult the Intel Linux kernel group for how to do this correctly, I will not accept the patch from you unless you have someone from that group signed off on it as well. Just slow down and get it right, don't waste everyone's time here please. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 15/16] checkpatch: Add warning on deprecated walk_iomem_res
On 12/25/2015 5:05 PM, Joe Perches wrote:
On Fri, 2015-12-25 at 15:09 -0700, Toshi Kani wrote:
Use of walk_iomem_res() is deprecated in new code. Change
checkpatch.pl to check new use of walk_iomem_res() and suggest
to use walk_iomem_res_desc() instead.
[]
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
@@ -3424,6 +3424,12 @@ sub process {
}
}
+# check for uses of walk_iomem_res()
+ if ($line =~ /\bwalk_iomem_res\(/) {
+ WARN("walk_iomem_res",
+"Use of walk_iomem_res is deprecated, please use
walk_iomem_res_desc instead\n" . $herecurr)
+ }
+
# check for new typedefs, only function parameters and sparse annotations
# make sense.
if ($line =~ /\btypedef\s/ &&
There are 6 uses of this function in the entire kernel tree.
Why not just change them, remove the function and avoid this?
Sorry, I should have put some background in the description. We have
discussed if we can remove walk_iomem_res() in the thread below.
https://lkml.org/lkml/2015/12/23/248
But this may depend on how we deal with the last remaining caller,
walk_iomem_res() with "GART", being discussed in the thread below. I
will update according to the outcome.
https://lkml.org/lkml/2015/12/26/144
Thanks,
-Toshi
--
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 RESEND v2 1/1] fix a dead loop when in heavy low memory
From: Figo
Android System UI hang when run heavy monkey stress test.
V2: add more detail about how to re-produce this issue, the
important is install more than 100 apps/games.
Re-produce step:
Run this monkey stress test script with more than 100
apps/games installed:
adb shell "monkey --ignore-crashes --ignore-timeouts
--kill-process-after-error --ignore-security-exceptions
--throttle 200 -v 2000"
kernel log:
[ 1526.272125] lowmem_scan start: 128, 213da, ofree -9849 34419, ma 529
[ 1526.272260] lowmemorykiller: select 'dTi-lm' (27289), adj 647, size 10630,
to kill
[ 1526.272299] lowmem_d_timeout=4296194081
[ 1526.272303] Killing 'dTi-lm' (27289), adj 647,
[ 1526.272303]to free 42520kB on behalf of 'servicemanager' (2365) because
[ 1526.272303]cache 137676kB is below limit 221184kB for oom_score_adj 529
[ 1526.272303]Free memory is -39396kB above reserved
[ 1526.272304] lowmem_scan end: 128, 213da, return 10630
[ 1526.272710] lowmem_scan start: 128, 213da, ofree -9849 34373, ma 529
[ 1526.272832] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193081,
4296194081
[ 1526.274450] lowmem_scan start: 128, 280da, ofree -9601 34327, ma 529
[ 1526.274695] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193083,
4296194081
[ 1526.282292] lowmem_scan start: 128, 213da, ofree -9703 34327, ma 529
[ 1526.282727] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193090,
4296194081
[ 1526.316888] lowmem_scan start: 128, 213da, ofree -9766 34465, ma 529
[ 1526.317019] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
4296194081
[ 1526.319311] lowmem_scan start: 128, 213da, ofree -9856 34419, ma 529
[ 1526.319442] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
4296194081
[ 1526.322026] lowmem_scan start: 128, 280da, ofree -9841 34327, ma 529
[ 1526.360831] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193166,
4296194081
[ 1526.532233] lowmem_scan start: 128, 213da, ofree -9846 34511, ma 529
[ 1526.644046] lowmem_scan start: 128, 213da, ofree -9785 34235, ma 529
[ 1527.437578] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194246,
4296195109
[ 1527.442559] lowmem_scan start: 128, 213da, ofree -9850 41884, ma 529
[ 1527.459540] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194268,
4296195109
[ 1527.500352] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194309,
4296195109
when this happened, the android system UI will hang, no process can be
select to kill.
i found the the value of "lowmem_deathpending_timeout" will be modified
strangely, like in last killing, the value is 4296194081, but why not it
had changed to 4296195109? so it will cause the deadloop in low memory
state which will cause the android system UI hang, because no process will
be kill.
commit e5d7965f88a3 ("staging: android: lowmemorykiller: Don't wait more
than one second for a process to die") said wait 1 seconds, i think it no
need to wait 1 second, because we don't select the process with
"TIF_MEMDIE" to kill.
Signed-off-by: Figo.zhang
---
drivers/staging/android/lowmemorykiller.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index e679d84..13c7182 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -59,8 +59,6 @@ static int lowmem_minfree[6] = {
};
static int lowmem_minfree_size = 4;
-static unsigned long lowmem_deathpending_timeout;
-
#define lowmem_print(level, x...) \
do {\
if (lowmem_debug_level >= (level)) \
@@ -128,11 +126,9 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
if (!p)
continue;
- if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
- time_before_eq(jiffies, lowmem_deathpending_timeout)) {
+ if (test_tsk_thread_flag(p, TIF_MEMDIE)) {
task_unlock(p);
- rcu_read_unlock();
- return 0;
+ continue;
}
oom_score_adj = p->signal->oom_score_adj;
if (oom_score_adj < min_score_adj) {
@@ -170,7 +166,6 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
selected->pid, selected->comm,
selected_oom_score_adj, selected_tasksize);
- lowmem_deathpending_timeout = jiffies + HZ;
rem += selected_tasksize;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 14/16] x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search
On 12/26/2015 9:05 AM, Minfei Huang wrote:
Ccing kexec maillist.
On 12/25/15 at 03:09pm, Toshi Kani wrote:
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index c245085..e2bd737 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -522,10 +522,10 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
unsigned long bufsz,
/* Walk the RAM ranges and allocate a suitable range for the buffer */
if (image->type == KEXEC_TYPE_CRASH)
- ret = walk_iomem_res("Crash kernel",
-IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
-crashk_res.start, crashk_res.end, kbuf,
-locate_mem_hole_callback);
+ ret = walk_iomem_res_desc(IORES_DESC_CRASH_KERNEL,
Since crashk_res's desc has been assigned to IORES_DESC_CRASH_KERNEL, it
is better to use crashk_res.desc, instead of using
IORES_DESC_CRASH_KERNEL directly.
Sounds good. I will change it to use crashk_res.desc.
Thanks,
-Toshi
--
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] SUNRPC: restore fair scheduling to priority queues.
On Tue, Dec 15, 2015 at 10:10 PM, NeilBrown wrote:
> On Wed, Dec 16 2015, Trond Myklebust wrote:
>
>> On Tue, Dec 15, 2015 at 6:44 PM, NeilBrown wrote:
>>>
>>> Commit: c05eecf63610 ("SUNRPC: Don't allow low priority tasks to pre-empt
>>> higher priority ones")
>>>
>>> removed the 'fair scheduling' feature from SUNRPC priority queues.
>>> This feature caused problems for some queues (send queue and session slot
>>> queue)
>>> but is still needed for others, particularly the tcp slot queue.
>>>
>>> Without fairness, reads (priority 1) can starve background writes
>>> (priority 0) so a streaming read can cause writeback to block
>>> indefinitely. This is not easy to measure with default settings as
>>> the current slot table size is much larger than the read-ahead size.
>>> However if the slot-table size is reduced (seen when backporting to
>>> older kernels with a limited size) the problem is easily demonstrated.
>>>
>>> This patch conditionally restores fair scheduling. It is now the
>>> default unless rpc_sleep_on_priority() is called directly. Then the
>>> queue switches to strict priority observance.
>>>
>>> As that function is called for both the send queue and the session
>>> slot queue and not for any others, this has exactly the desired
>>> effect.
>>>
>>> The "count" field that was removed by the previous patch is restored.
>>> A value for '255' means "strict priority queuing, no fair queuing".
>>> Any other value is a could of owners to be processed before switching
>>> to a different priority level, just like before.
>> Are we sure there is value in keeping FLUSH_LOWPRI for background writes?
>
> There is currently also FLUSH_HIGHPRI for "for_reclaim" writes.
> Should they be allowed to starve reads?
>
> If you treated all reads and writed the same, then I can't see value in
> restoring fair scheduling. If there is any difference, then I suspect
> we do need the fairness.
I disagree. Reclaiming memory should always be able to pre-empt
"interactive" features such as read. Everything goes down the toilet
when we force the kernel into situations where it needs to swap.
Cheers
Trond
--
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 14/16] x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search
+ cc: kexec list On 12/26/2015 3:38 AM, Borislav Petkov wrote: On Fri, Dec 25, 2015 at 03:09:23PM -0700, Toshi Kani wrote: Change to call walk_iomem_res_desc() for searching resource entries with the following names: "ACPI Tables" "ACPI Non-volatile Storage" "Persistent Memory (legacy)" "Crash kernel" Note, the caller of walk_iomem_res() with "GART" is left unchanged because this entry may be initialized by out-of-tree drivers, which do not have 'desc' set to IORES_DESC_GART. There's this out-of-tree bogus argument again. :\ Why do we care about out-of-tree drivers? You can just as well fix the "GART" case too and kill walk_iomem_res() altogether... Right, but I do not see any "GART" case in the upstream code, so I cannot change it... Thanks, -Toshi -- 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 RESEND v2 1/1] fix a dead loop when in heavy low memory
From: Figo
Android System UI hang when run heavy monkey stress test.
V2: add more detail about how to re-produce this issue, the
important is install more than 100 apps/games.
Re-produce step:
Run this monkey stress test script with more than 100
apps/games installed:
--kill-process-after-error --ignore-security-exceptions
--throttle 200 -v 2000"
kernel log:
[ 1526.272125] lowmem_scan start: 128, 213da, ofree -9849 34419, ma 529
[ 1526.272260] lowmemorykiller: select 'dTi-lm' (27289), adj 647, size 10630,
to kill
[ 1526.272299] lowmem_d_timeout=4296194081
[ 1526.272303] Killing 'dTi-lm' (27289), adj 647,
[ 1526.272303]to free 42520kB on behalf of 'servicemanager' (2365) because
[ 1526.272303]cache 137676kB is below limit 221184kB for oom_score_adj 529
[ 1526.272303]Free memory is -39396kB above reserved
[ 1526.272304] lowmem_scan end: 128, 213da, return 10630
[ 1526.272710] lowmem_scan start: 128, 213da, ofree -9849 34373, ma 529
[ 1526.272832] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193081,
4296194081
[ 1526.274450] lowmem_scan start: 128, 280da, ofree -9601 34327, ma 529
[ 1526.274695] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193083,
4296194081
[ 1526.282292] lowmem_scan start: 128, 213da, ofree -9703 34327, ma 529
[ 1526.282727] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193090,
4296194081
[ 1526.316888] lowmem_scan start: 128, 213da, ofree -9766 34465, ma 529
[ 1526.317019] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
4296194081
[ 1526.319311] lowmem_scan start: 128, 213da, ofree -9856 34419, ma 529
[ 1526.319442] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193125,
4296194081
[ 1526.322026] lowmem_scan start: 128, 280da, ofree -9841 34327, ma 529
[ 1526.360831] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296193166,
4296194081
[ 1526.532233] lowmem_scan start: 128, 213da, ofree -9846 34511, ma 529
[ 1526.644046] lowmem_scan start: 128, 213da, ofree -9785 34235, ma 529
[ 1527.437578] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194246,
4296195109
[ 1527.442559] lowmem_scan start: 128, 213da, ofree -9850 41884, ma 529
[ 1527.459540] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194268,
4296195109
[ 1527.500352] lowmem: TIF_MEMDIE, adj=647, dTi-lm, jiffies=4296194309,
4296195109
when this happened, the android system UI will hang, no process can be
select to kill.
i found the the value of "lowmem_deathpending_timeout" will be modified
strangely, like in last killing, the value is 4296194081, but why not it
had changed to 4296195109? so it will cause the deadloop in low memory
state which will cause the android system UI hang, because no process will
be kill.
commit e5d7965f88a3 ("staging: android: lowmemorykiller: Don't wait more
than one second for a process to die") said wait 1 seconds, i think it no
need to wait 1 second, because we don't select the process with
"TIF_MEMDIE" to kill.
Signed-off-by: Figo.zhang
---
drivers/staging/android/lowmemorykiller.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index e679d84..13c7182 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -59,8 +59,6 @@ static int lowmem_minfree[6] = {
};
static int lowmem_minfree_size = 4;
-static unsigned long lowmem_deathpending_timeout;
-
#define lowmem_print(level, x...) \
do {\
if (lowmem_debug_level >= (level)) \
@@ -128,11 +126,9 @@ static unsigned long lowmem_scan(struct shrinker *s,
struct shrink_control *sc)
if (!p)
continue;
- if (test_tsk_thread_flag(p, TIF_MEMDIE) &&
- time_before_eq(jiffies, lowmem_deathpending_timeout)) {
+ if (test_tsk_thread_flag(p, TIF_MEMDIE)) {
task_unlock(p);
- rcu_read_unlock();
- return 0;
+ continue;
}
oom_score_adj = p->signal->oom_score_adj;
if (oom_score_adj < min_score_adj) {
@@ -170,7 +166,6 @@ static unsigned long lowmem_scan(struct shrinker *s, struct
shrink_control *sc)
lowmem_print(1, "send sigkill to %d (%s), adj %hd, size %d\n",
selected->pid, selected->comm,
selected_oom_score_adj, selected_tasksize);
- lowmem_deathpending_timeout = jiffies + HZ;
rem += selected_tasksize;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] fix a dead loop when in heavy low memory
On Sun, Dec 27, 2015 at 12:19:08AM +, Zhang, Tianfei wrote: > > Great, please use that, but why does your email address show a different > > name? Intel has standards that you have to follow when submitting Linux > > kernel patches, please consult them before you resend. > > > > Hi greg, I should resend this patch using [PATCH RESEND v2 1/1]? I can't take it as-is, so of course you should resend it... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/1] fix a dead loop when in heavy low memory
> Great, please use that, but why does your email address show a different
> name? Intel has standards that you have to follow when submitting Linux
> kernel patches, please consult them before you resend.
>
Hi greg, I should resend this patch using [PATCH RESEND v2 1/1]?
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2 1/1] fix a dead loop when in heavy low memory
On Sat, Dec 26, 2015 at 11:24:14PM +, Zhang, Tianfei wrote: > > > Android System UI hang when run heavy monkey stress test. > > > > What changed from v1 of this patch? Please describe that below the --- > > line. > V2，I just modify my comments. Then say so. How am I supposed to know? > > > Signed-off-by: Figo > > > > I need a "full" name here, not a "short" name, sorry, before I can do > > anything > > with this patch. > > my name? my Full name is Figo.zhang Great, please use that, but why does your email address show a different name? Intel has standards that you have to follow when submitting Linux kernel patches, please consult them before you resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] fix a dead loop when in heavy low memory
On Sun, Dec 27, 2015 at 12:42:31AM +0100, Harald Arnesen wrote: > Greg KH [2015-12-26 19:12]: > > > I need a "full" name here, not a "short" name, sorry, before I can do > > anything with this patch. > > I don't know if that is the case here, but: > > You know, of course, that there are societies in this world where only > one name is used? Yes, but that obviously is not the case here, please give me more credit, I've been dealing with this for a _very_ long time... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function
On Sat, 2015-12-26 at 13:12 -0500, David Miller wrote: > IDE is in deep freeze maintainence mode. > > Therefore patches that perform simplications and cleanups will > not be accepted. Maybe there should be something like a README in drivers/ide that says that. Maybe the MAINTAINERS entry for "IDE SUBSYSTEM" should be something like: S: Frozen - critical fixes only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] fix a dead loop when in heavy low memory
Greg KH [2015-12-26 19:12]: > I need a "full" name here, not a "short" name, sorry, before I can do > anything with this patch. I don't know if that is the case here, but: You know, of course, that there are societies in this world where only one name is used? -- Hilsen Harald -- 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] fix a dead loop when in heavy low memory
> > Android System UI hang when run heavy monkey stress test.
>
> What changed from v1 of this patch? Please describe that below the ---
> line.
V2，I just modify my comments.
>
> >
> > Signed-off-by: Figo
>
> I need a "full" name here, not a "short" name, sorry, before I can do anything
> with this patch.
my name? my Full name is Figo.zhang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH] sparc64: fix incorrect sign extension in sys_sparc64_personality
The value returned by sys_personality has type "long int".
It is saved to a variable of type "int", which is not a problem
yet because the type of task_struct->pesonality is "unsigned int".
The problem is the sign extension from "int" to "long int"
that happens on return from sys_sparc64_personality.
For example, a userspace call personality((unsigned) -EINVAL) will
result to any subsequent personality call, including absolutely
harmless read-only personality(0x) call, failing with
errno set to EINVAL.
Signed-off-by: Dmitry V. Levin
Cc:
---
arch/sparc/kernel/sys_sparc_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 30e7ddb..c690c8e 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -413,15 +413,15 @@ out:
SYSCALL_DEFINE1(sparc64_personality, unsigned long, personality)
{
- int ret;
+ long ret;
if (personality(current->personality) == PER_LINUX32 &&
personality(personality) == PER_LINUX)
personality |= PER_LINUX32;
ret = sys_personality(personality);
if (personality(ret) == PER_LINUX32)
ret &= ~PER_LINUX32;
return ret;
}
--
ldv
--
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/3] cpufreq: Make cpufreq_boost_supported() static
From: Rafael J. Wysocki
cpufreq_boost_supported() is not used outside of cpufreq.c, so make
it static.
While at it, refactor it as a one-liner (which it really is).
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/cpufreq.c |8 ++--
include/linux/cpufreq.h |5 -
2 files changed, 2 insertions(+), 11 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -2330,14 +2330,10 @@ int cpufreq_boost_trigger_state(int stat
return ret;
}
-int cpufreq_boost_supported(void)
+static bool cpufreq_boost_supported(void)
{
- if (likely(cpufreq_driver))
- return cpufreq_driver->boost_supported;
-
- return 0;
+ return likely(cpufreq_driver) && cpufreq_driver->boost_supported;
}
-EXPORT_SYMBOL_GPL(cpufreq_boost_supported);
static int create_boost_sysfs_file(void)
{
Index: linux-pm/include/linux/cpufreq.h
===
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -574,7 +574,6 @@ ssize_t cpufreq_show_cpus(const struct c
#ifdef CONFIG_CPU_FREQ
int cpufreq_boost_trigger_state(int state);
-int cpufreq_boost_supported(void);
int cpufreq_boost_enabled(void);
int cpufreq_enable_boost_support(void);
bool policy_has_boost_freq(struct cpufreq_policy *policy);
@@ -583,10 +582,6 @@ static inline int cpufreq_boost_trigger_
{
return 0;
}
-static inline int cpufreq_boost_supported(void)
-{
- return 0;
-}
static inline int cpufreq_boost_enabled(void)
{
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/
[PATCH 0/3] cpufreq: Boost cleanup
Hi, This series cleans up a few things related to the boost sysfs attribute used by cpufreq. [1/3] - Make local function static. [2/3] - Simplify boost-related code in acpi-cpufreq. [3/3] - Simplify boost-related core code. Thanks, 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/
[PATCH 3/3] cpufreq: Simplify core code related to boost support
From: Rafael J. Wysocki
Notice that the boost_supported field in struct cpufreq_driver is
redundant, because the driver's ->set_boost callback may be left
unset if "boost" is not supported. Moreover, the only driver
populating the ->set_boost callback is acpi_cpufreq, so make it
avoid populating that callback if "boost" is not supported, rework
the core to check ->set_boost instead of boost_supported to
verify "boost" support and drop boost_supported which isn't
used any more.
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/acpi-cpufreq.c |5 ++---
drivers/cpufreq/cpufreq.c | 22 +++---
include/linux/cpufreq.h|1 -
3 files changed, 9 insertions(+), 19 deletions(-)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -164,7 +164,7 @@ static ssize_t store_cpb(struct cpufreq_
int ret;
unsigned int val = 0;
- if (!acpi_cpufreq_driver.boost_supported)
+ if (!acpi_cpufreq_driver.set_boost)
return -EINVAL;
ret = kstrtouint(buf, 10, );
@@ -900,7 +900,6 @@ static struct cpufreq_driver acpi_cpufre
.resume = acpi_cpufreq_resume,
.name = "acpi-cpufreq",
.attr = acpi_cpufreq_attr,
- .set_boost = set_boost,
};
static void __init acpi_cpufreq_boost_init(void)
@@ -911,7 +910,7 @@ static void __init acpi_cpufreq_boost_in
if (!msrs)
return;
- acpi_cpufreq_driver.boost_supported = true;
+ acpi_cpufreq_driver.set_boost = set_boost;
acpi_cpufreq_driver.boost_enabled = boost_state(0);
cpu_notifier_register_begin();
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -2332,23 +2332,13 @@ int cpufreq_boost_trigger_state(int stat
static bool cpufreq_boost_supported(void)
{
- return likely(cpufreq_driver) && cpufreq_driver->boost_supported;
+ return likely(cpufreq_driver) && cpufreq_driver->set_boost;
}
static int create_boost_sysfs_file(void)
{
int ret;
- if (!cpufreq_boost_supported())
- return 0;
-
- /*
-* Check if driver provides function to enable boost -
-* if not, use cpufreq_boost_set_sw as default
-*/
- if (!cpufreq_driver->set_boost)
- cpufreq_driver->set_boost = cpufreq_boost_set_sw;
-
ret = sysfs_create_file(cpufreq_global_kobject, );
if (ret)
pr_err("%s: cannot register global BOOST sysfs file\n",
@@ -2371,7 +2361,7 @@ int cpufreq_enable_boost_support(void)
if (cpufreq_boost_supported())
return 0;
- cpufreq_driver->boost_supported = true;
+ cpufreq_driver->set_boost = cpufreq_boost_set_sw;
/* This will get removed on driver unregister */
return create_boost_sysfs_file();
@@ -2431,9 +2421,11 @@ int cpufreq_register_driver(struct cpufr
if (driver_data->setpolicy)
driver_data->flags |= CPUFREQ_CONST_LOOPS;
- ret = create_boost_sysfs_file();
- if (ret)
- goto err_null_driver;
+ if (cpufreq_boost_supported()) {
+ ret = create_boost_sysfs_file();
+ if (ret)
+ goto err_null_driver;
+ }
ret = subsys_interface_register(_interface);
if (ret)
Index: linux-pm/include/linux/cpufreq.h
===
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -278,7 +278,6 @@ struct cpufreq_driver {
struct freq_attr **attr;
/* platform specific boost support code */
- boolboost_supported;
boolboost_enabled;
int (*set_boost)(int state);
};
--
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/3] cpufreq: acpi-cpufreq: Simplify boost-related code
From: Rafael J. Wysocki
The store_boost() routine is only used by store_cpb(), so move
the code from it directly to that function and rename _store_boost()
to set_boost() to make its name reflect the name of the driver
callback pointing to it.
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/acpi-cpufreq.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -135,7 +135,7 @@ static void boost_set_msrs(bool enable,
wrmsr_on_cpus(cpumask, msr_addr, msrs);
}
-static int _store_boost(int val)
+static int set_boost(int val)
{
get_online_cpus();
boost_set_msrs(val, cpu_online_mask);
@@ -158,29 +158,24 @@ static ssize_t show_freqdomain_cpus(stru
cpufreq_freq_attr_ro(freqdomain_cpus);
#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
-static ssize_t store_boost(const char *buf, size_t count)
+static ssize_t store_cpb(struct cpufreq_policy *policy, const char *buf,
+size_t count)
{
int ret;
- unsigned long val = 0;
+ unsigned int val = 0;
if (!acpi_cpufreq_driver.boost_supported)
return -EINVAL;
- ret = kstrtoul(buf, 10, );
- if (ret || (val > 1))
+ ret = kstrtouint(buf, 10, );
+ if (ret || val > 1)
return -EINVAL;
- _store_boost((int) val);
+ set_boost(val);
return count;
}
-static ssize_t store_cpb(struct cpufreq_policy *policy, const char *buf,
-size_t count)
-{
- return store_boost(buf, count);
-}
-
static ssize_t show_cpb(struct cpufreq_policy *policy, char *buf)
{
return sprintf(buf, "%u\n", acpi_cpufreq_driver.boost_enabled);
@@ -905,7 +900,7 @@ static struct cpufreq_driver acpi_cpufre
.resume = acpi_cpufreq_resume,
.name = "acpi-cpufreq",
.attr = acpi_cpufreq_attr,
- .set_boost = _store_boost,
+ .set_boost = set_boost,
};
static void __init acpi_cpufreq_boost_init(void)
--
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] Fix ld-version.sh to handle large 3rd version part
The ld-version.sh script doesn't handle versions with large (>= 10) 3rd
version components, because the 2nd component is only multiplied by 10
times that of the 3rd component.
For example the following version string:
GNU ld (Codescape GNU Tools 2015.06-05 for MIPS MTI Linux) 2.24.90
gives a bogus version number:
2000
+ 240
+ 90 = 2330
Breakage, confusion and mole-whacking ensues.
Increase the multipliers of the first two version components by a factor
of 10 to give space for a 3rd components of up to 99, and update the
sole user of ld-ifversion (MIPS VDSO) accordingly.
Signed-off-by: James Hogan
Cc: Ralf Baechle
Cc: Andi Kleen
Cc: Michal Marek
Cc: Guenter Roeck
Cc: linux-m...@linux-mips.org
---
This is based on top of mips-for-linux-next with Guenter's patch "MIPS:
VDSO: Fix build error with binutils 2.24 and earlier" applied first.
Ralf: Please consider applying to hopefully fix the VDSO build issue
once and for all.
Andi/Michal: If this patch gets merged, I'm guessing the patch "Kbuild,
lto: Add Link Time Optimization support v3" will need tweaking when it
gets merged.
---
arch/mips/vdso/Makefile | 2 +-
scripts/ld-version.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 14568900fc1d..ee3617c0c5e2 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -26,7 +26,7 @@ aflags-vdso := $(ccflags-vdso) \
# the comments on that file.
#
ifndef CONFIG_CPU_MIPSR6
- ifeq ($(call ld-ifversion, -lt, 2250, y),y)
+ ifeq ($(call ld-ifversion, -lt, 22500, y),y)
$(warning MIPS VDSO requires binutils >= 2.25)
obj-vdso-y := $(filter-out gettimeofday.o, $(obj-vdso-y))
ccflags-vdso += -DDISABLE_MIPS_VDSO
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 198580d245e0..0b67edc5bc6f 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -3,6 +3,6 @@
{
gsub(".*)", "");
split($1,a, ".");
- print a[1]*1000 + a[2]*10 + a[3]*1 + a[4]*100 + a[5];
+ print a[1]*1 + a[2]*100 + a[3]*1 + a[4]*100 + a[5];
exit
}
--
2.4.10
--
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 8/8] ARM: bcm2835: Add Kconfig support for bcm2836
Eric Anholt writes: > This should be a complete port of bcm2835 functionality to bcm2836 > (Raspberry Pi 2). > > Signed-off-by: Eric Anholt > --- > > v2: Implement Arnd's feedback to not split to ARCH_BCM2836, and > instead use more conditionals in ARCH_BCM2835. Also reduce diff > between 2835 and 2836. > > arch/arm/Kconfig.debug | 10 -- > arch/arm/boot/dts/Makefile | 3 ++- > arch/arm/mach-bcm/Kconfig | 8 > 3 files changed, 14 insertions(+), 7 deletions(-) I noticed a minor bug in this commit, that the dts/Makefile hunk should be in the Pi2 DT patch, instead. Otherwise the -soc branch for submitting this doesn't build on its own before the merge of all the branches together. signature.asc Description: PGP signature
Re: [PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
On 12/27/2015 01:32 AM, Julia Lawall wrote:
The error return value of platform_get_irq seems to often get dropped.
Signed-off-by: Julia Lawall
---
v2: Check for the direct return case also. Added some mailing lists of
common offenders.
diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..44680d0
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,58 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0,
but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+//
+
+@r depends on context || org || report@
+constant C;
+statement S;
+expression e, ret;
+position j0, j1;
+@@
+
+* e@j0 = platform_get_irq(...);
+(
+if@j1 (...) {
+ ...
+ return -C;
+} else S
+|
+if@j1 (...) {
+ ...
+ ret = -C;
+ ...
+ return ret;
+} else S
Well, this seems to also cover the (e <= 0) checks which do make same sense
in the light of Linus considering IRQ0 invalid. So I'd be more specific about
the checks here -- 0 should indeed be overridden with something if it's
considered invalid.
That's what the limitations section says (lines with #). This doesn't
Ah, failed to notice those, only saw after replying.
make any changes, it only makes warnings, which should include the
limitations information, so perhaps people can consider what it is that
they really intend to do.
>
If you think this is not a good idea, then I can make the test more
specific.
Well, looking again, the patch should be good. I just thought its goal was
to fix the code as well...
julia
MBR, Sergei
--
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] coccinelle: api: check for propagation of error from platform_get_irq
On Sun, 27 Dec 2015, Sergei Shtylyov wrote:
> On 12/26/2015 11:58 PM, Julia Lawall wrote:
>
> > The error return value of platform_get_irq seems to often get dropped.
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> >
> > v2: Check for the direct return case also. Added some mailing lists of
> > common offenders.
> >
> > diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
> > b/scripts/coccinelle/api/platform_get_irq_return.cocci
> > new file mode 100644
> > index 000..44680d0
> > --- /dev/null
> > +++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
> > @@ -0,0 +1,58 @@
> > +/// Propagate the return value of platform_get_irq.
> > +//# Sometimes the return value of platform_get_irq is tested using <= 0,
> > but 0
> > +//# might not be an appropriate return value in an error case.
> > +///
> > +// Confidence: Moderate
> > +// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
> > +// URL: http://coccinelle.lip6.fr/
> > +// Options: --no-includes --include-headers
> > +
> > +virtual context
> > +virtual org
> > +virtual report
> > +
> > +//
> >
> > +
> > +@r depends on context || org || report@
> > +constant C;
> > +statement S;
> > +expression e, ret;
> > +position j0, j1;
> > +@@
> > +
> > +* e@j0 = platform_get_irq(...);
> > +(
> > +if@j1 (...) {
> > + ...
> > + return -C;
> > +} else S
> > +|
> > +if@j1 (...) {
> > + ...
> > + ret = -C;
> > + ...
> > + return ret;
> > +} else S
>
>Well, this seems to also cover the (e <= 0) checks which do make same sense
> in the light of Linus considering IRQ0 invalid. So I'd be more specific about
> the checks here -- 0 should indeed be overridden with something if it's
> considered invalid.
That's what the limitations section says (lines with #). This doesn't
make any changes, it only makes warnings, which should include the
limitations information, so perhaps people can consider what it is that
they really intend to do.
If you think this is not a good idea, then I can make the test more
specific.
julia
--
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] coccinelle: api: check for propagation of error from platform_get_irq
On 12/26/2015 11:58 PM, Julia Lawall wrote:
The error return value of platform_get_irq seems to often get dropped.
Signed-off-by: Julia Lawall
---
v2: Check for the direct return case also. Added some mailing lists of
common offenders.
diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..44680d0
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,58 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0, but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+//
+
+@r depends on context || org || report@
+constant C;
+statement S;
+expression e, ret;
+position j0, j1;
+@@
+
+* e@j0 = platform_get_irq(...);
+(
+if@j1 (...) {
+ ...
+ return -C;
+} else S
+|
+if@j1 (...) {
+ ...
+ ret = -C;
+ ...
+ return ret;
+} else S
Well, this seems to also cover the (e <= 0) checks which do make same
sense in the light of Linus considering IRQ0 invalid. So I'd be more specific
about the checks here -- 0 should indeed be overridden with something if it's
considered invalid.
MBR, Sergei
--
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] USB: usbmon: remove assignment from IS_ERR argument
The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S1,S2; @@ +e1 = e2; if (IS_ERR( e1 - = e2 )) S1 else S2 // Signed-off-by: Julia Lawall --- drivers/usb/mon/mon_text.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/mon/mon_text.c b/drivers/usb/mon/mon_text.c index 98e4f63..e59334b 100644 --- a/drivers/usb/mon/mon_text.c +++ b/drivers/usb/mon/mon_text.c @@ -387,7 +387,8 @@ static ssize_t mon_text_read_t(struct file *file, char __user *buf, struct mon_event_text *ep; struct mon_text_ptr ptr; - if (IS_ERR(ep = mon_text_read_wait(rp, file))) + ep = mon_text_read_wait(rp, file); + if (IS_ERR(ep)) return PTR_ERR(ep); mutex_lock(>printf_lock); ptr.cnt = 0; @@ -414,7 +415,8 @@ static ssize_t mon_text_read_u(struct file *file, char __user *buf, struct mon_event_text *ep; struct mon_text_ptr ptr; - if (IS_ERR(ep = mon_text_read_wait(rp, file))) + ep = mon_text_read_wait(rp, file); + if (IS_ERR(ep)) return PTR_ERR(ep); mutex_lock(>printf_lock); ptr.cnt = 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/
[PATCH 0/2] remove assignment from IS_ERR argument
The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S1,S2; @@ +e1 = e2; if (IS_ERR( e1 - = e2 )) S1 else S2 // --- drivers/usb/mon/mon_text.c |6 -- ipc/mqueue.c |3 ++- 2 files changed, 6 insertions(+), 3 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/
[PATCH 1/2] ipc/mqueue: remove assignment from IS_ERR argument
The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S1,S2; @@ +e1 = e2; if (IS_ERR( e1 - = e2 )) S1 else S2 // Signed-off-by: Julia Lawall --- ipc/mqueue.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipc/mqueue.c b/ipc/mqueue.c index f4617cf..3975abc 100644 --- a/ipc/mqueue.c +++ b/ipc/mqueue.c @@ -786,7 +786,8 @@ SYSCALL_DEFINE4(mq_open, const char __user *, u_name, int, oflag, umode_t, mode, audit_mq_open(oflag, mode, u_attr ? : NULL); - if (IS_ERR(name = getname(u_name))) + name = getname(u_name); + if (IS_ERR(name)) return PTR_ERR(name); fd = get_unused_fd_flags(O_CLOEXEC); -- 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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote:
> ptrace_has_cap() checks whether the current process should be
> treated as having a certain capability for ptrace checks
> against another process. Until now, this was equivalent to
> has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
>
> However, if a root-owned process wants to enter a user
> namespace for some reason without knowing who owns it and
> therefore can't change to the namespace owner's uid and gid
> before entering, as soon as it has entered the namespace,
> the namespace owner can attach to it via ptrace and thereby
> gain access to its uid and gid.
>
> While it is possible for the entering process to switch to
> the uid of a claimed namespace owner before entering,
> causing the attempt to enter to fail if the claimed uid is
> wrong, this doesn't solve the problem of determining an
> appropriate gid.
>
> With this change, the entering process can first enter the
> namespace and then safely inspect the namespace's
> properties, e.g. through /proc/self/{uid_map,gid_map},
> assuming that the namespace owner doesn't have access to
> uid 0.
>
> Changed in v2: The caller needs to be capable in the
> namespace into which tcred's uids/gids can be mapped.
>
> Signed-off-by: Jann Horn
Acked-by: Serge Hallyn
> ---
> kernel/ptrace.c | 33 -
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index b760bae..260a08d 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -207,12 +208,34 @@ static int ptrace_check_attach(struct task_struct
> *child, bool ignore_state)
> return ret;
> }
>
> -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> {
> + struct user_namespace *tns = tcred->user_ns;
> +
> + /* When a root-owned process enters a user namespace created by a
> + * malicious user, the user shouldn't be able to execute code under
> + * uid 0 by attaching to the root-owned process via ptrace.
> + * Therefore, similar to the capable_wrt_inode_uidgid() check,
> + * verify that all the uids and gids of the target process are
> + * mapped into a namespace below the current one in which the caller
> + * is capable.
> + * No fsuid/fsgid check because __ptrace_may_access doesn't do it
> + * either.
> + */
> + while (
> + !kuid_has_mapping(tns, tcred->euid) ||
> + !kuid_has_mapping(tns, tcred->suid) ||
> + !kuid_has_mapping(tns, tcred->uid) ||
> + !kgid_has_mapping(tns, tcred->egid) ||
> + !kgid_has_mapping(tns, tcred->sgid) ||
> + !kgid_has_mapping(tns, tcred->gid)) {
> + tns = tns->parent;
> + }
> +
> if (mode & PTRACE_MODE_NOAUDIT)
> - return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
> + return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
> else
> - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
> }
>
> /* Returns 0 on success, -errno on denial. */
> @@ -241,7 +264,7 @@ static int __ptrace_may_access(struct task_struct *task,
> unsigned int mode)
> gid_eq(cred->gid, tcred->sgid) &&
> gid_eq(cred->gid, tcred->gid))
> goto ok;
> - if (ptrace_has_cap(tcred->user_ns, mode))
> + if (ptrace_has_cap(tcred, mode))
> goto ok;
> rcu_read_unlock();
> return -EPERM;
> @@ -252,7 +275,7 @@ ok:
> dumpable = get_dumpable(task->mm);
> rcu_read_lock();
> if (dumpable != SUID_DUMP_USER &&
> - !ptrace_has_cap(__task_cred(task)->user_ns, mode)) {
> + !ptrace_has_cap(__task_cred(task), mode)) {
> rcu_read_unlock();
> return -EPERM;
> }
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 10:27:33PM +0100, Jann Horn wrote:
> On Sat, Dec 26, 2015 at 03:17:29PM -0600, Serge E. Hallyn wrote:
> > On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote:
> > > ptrace_has_cap() checks whether the current process should be
> > > treated as having a certain capability for ptrace checks
> > > against another process. Until now, this was equivalent to
> > > has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
> > >
> > > However, if a root-owned process wants to enter a user
> > > namespace for some reason without knowing who owns it and
> > > therefore can't change to the namespace owner's uid and gid
> > > before entering, as soon as it has entered the namespace,
> > > the namespace owner can attach to it via ptrace and thereby
> > > gain access to its uid and gid.
> > >
> > > While it is possible for the entering process to switch to
> > > the uid of a claimed namespace owner before entering,
> > > causing the attempt to enter to fail if the claimed uid is
> > > wrong, this doesn't solve the problem of determining an
> > > appropriate gid.
> > >
> > > With this change, the entering process can first enter the
> > > namespace and then safely inspect the namespace's
> > > properties, e.g. through /proc/self/{uid_map,gid_map},
> > > assuming that the namespace owner doesn't have access to
> > > uid 0.
> > >
> > > Changed in v2: The caller needs to be capable in the
> > > namespace into which tcred's uids/gids can be mapped.
> > >
> > > Signed-off-by: Jann Horn
> > > ---
> > > kernel/ptrace.c | 33 -
> > > 1 file changed, 28 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> > > index b760bae..260a08d 100644
> > > --- a/kernel/ptrace.c
> > > +++ b/kernel/ptrace.c
> > > @@ -20,6 +20,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -207,12 +208,34 @@ static int ptrace_check_attach(struct task_struct
> > > *child, bool ignore_state)
> > > return ret;
> > > }
> > >
> > > -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> > > +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> > > {
> > > + struct user_namespace *tns = tcred->user_ns;
> > > +
> > > + /* When a root-owned process enters a user namespace created by a
> > > + * malicious user, the user shouldn't be able to execute code under
> > > + * uid 0 by attaching to the root-owned process via ptrace.
> > > + * Therefore, similar to the capable_wrt_inode_uidgid() check,
> > > + * verify that all the uids and gids of the target process are
> > > + * mapped into a namespace below the current one in which the caller
> > > + * is capable.
> > > + * No fsuid/fsgid check because __ptrace_may_access doesn't do it
> > > + * either.
> > > + */
> > > + while (
> > > + !kuid_has_mapping(tns, tcred->euid) ||
> > > + !kuid_has_mapping(tns, tcred->suid) ||
> > > + !kuid_has_mapping(tns, tcred->uid) ||
> > > + !kgid_has_mapping(tns, tcred->egid) ||
> > > + !kgid_has_mapping(tns, tcred->sgid) ||
> > > + !kgid_has_mapping(tns, tcred->gid)) {
> > > + tns = tns->parent;
> >
> > Sorry, i can't quite remember - is there a way for a task in init_user_ns
> > to have
> > INVALID_UID | INVALID_GID ? I.e. any point in breaking here if tns ==
> > _user_n?
>
> I assumed that there isn't because the comment above the definition of
> from_kuid()
> says so. Checking... the syscalls for setting uid/gid seem to enforce that
> uid/gid
> aren't -1, and setuid/setgid executables require the uid/gid to be mapped. So
> it
> seems to be true.
Yeah, I knew I'd read it somewhere but couldn't find the comment. 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/4] bcm2836 (Raspberry Pi 2) interrupt controller updates for 4.5
While the 2836 interrupt controller technically works, it would be nice to merge these improvements to it, adding SMP booting, fixing the timers, and fixing an apparently-spurious error message. Patches 1, 2 were seen before in the full Pi 2 series I sent recently, now with their summary prefixes fixed and a minor style cleanup to #2. Patches 3, 4 are new, but trivial. Andrea Merello (3): irqchip: bcm2836: Add SMP support for the 2836 irqchip: bcm2836: tolerate IRQs while no flag is set in ISR irqchip: bcm2836: make code more readable Eric Anholt (1): irqchip: bcm2836: Fix initialization of the LOCAL_IRQ_CNT*IRQ timers drivers/irqchip/irq-bcm2836.c | 55 +++ 1 file changed, 51 insertions(+), 4 deletions(-) -- 2.6.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 2/4] irqchip: bcm2836: Add SMP support for the 2836
From: Andrea Merello
The firmware sets the secondaries spinning waiting for a non-NULL
value to show up in the last IPI mailbox.
The original SMP port from the downstream tree was done by Andrea, and
Eric cleaned it up/rewrote it a few times from there.
Signed-off-by: Andrea Merello
Signed-off-by: Eric Anholt
---
v2: Merge into another CONFIG_SMP block.
drivers/irqchip/irq-bcm2836.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 6ec125e..59ac40c 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -53,14 +53,16 @@
/* Same status bits as above, but for FIQ. */
#define LOCAL_FIQ_PENDING0 0x070
/*
- * Mailbox0 write-to-set bits. There are 16 mailboxes, 4 per CPU, and
+ * Mailbox write-to-set bits. There are 16 mailboxes, 4 per CPU, and
* these bits are organized by mailbox number and then CPU number. We
* use mailbox 0 for IPIs. The mailbox's interrupt is raised while
* any bit is set.
*/
#define LOCAL_MAILBOX0_SET00x080
-/* Mailbox0 write-to-clear bits. */
+#define LOCAL_MAILBOX3_SET00x08c
+/* Mailbox write-to-clear bits. */
#define LOCAL_MAILBOX0_CLR00x0c0
+#define LOCAL_MAILBOX3_CLR00x0cc
#define LOCAL_IRQ_CNTPSIRQ 0
#define LOCAL_IRQ_CNTPNSIRQ1
@@ -220,6 +222,24 @@ static struct notifier_block
bcm2836_arm_irqchip_cpu_notifier = {
.notifier_call = bcm2836_arm_irqchip_cpu_notify,
.priority = 100,
};
+
+int __init bcm2836_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ unsigned long secondary_startup_phys =
+ (unsigned long)virt_to_phys((void *)secondary_startup);
+
+ dsb();
+ writel(secondary_startup_phys,
+ intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
+
+ return 0;
+}
+
+static const struct smp_operations bcm2836_smp_ops __initconst = {
+ .smp_boot_secondary = bcm2836_smp_boot_secondary,
+};
+
#endif
static const struct irq_domain_ops bcm2836_arm_irqchip_intc_ops = {
@@ -237,6 +257,7 @@ bcm2836_arm_irqchip_smp_init(void)
register_cpu_notifier(_arm_irqchip_cpu_notifier);
set_smp_cross_call(bcm2836_arm_irqchip_send_ipi);
+ smp_set_ops(_smp_ops);
#endif
}
--
2.6.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 3/4] irqchip: bcm2836: tolerate IRQs while no flag is set in ISR
From: Andrea Merello
On my RPi2 I got a lot of:
unexpected IRQ trap at vector 00
This happens because bcm2836_arm_irqchip_handle_irq() is sometimes
invoked even if the ISR is clear, and this case is not handled.
This patch explicitly handle this case, fixing the kernel complaints
about the bad IRQ lookup.
Signed-off-by: Andrea Merello
Reviewed-by: Eric Anholt
Signed-off-by: Eric Anholt
---
drivers/irqchip/irq-bcm2836.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 59ac40c..bb8f234 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -177,7 +177,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct
pt_regs *regs)
writel(1 << ipi, mailbox0);
handle_IPI(ipi, regs);
#endif
- } else {
+ } else if (stat) {
u32 hwirq = ffs(stat) - 1;
handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
--
2.6.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 4/4] irqchip: bcm2836: make code more readable
From: Andrea Merello
Avoid using hardcoded magics. We have a #define for this number.
No functional changes.
Signed-off-by: Andrea Merello
Reviewed-by: Eric Anholt
Signed-off-by: Eric Anholt
---
drivers/irqchip/irq-bcm2836.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index bb8f234..963065a 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -167,7 +167,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct
pt_regs *regs)
u32 stat;
stat = readl_relaxed(intc.base + LOCAL_IRQ_PENDING0 + 4 * cpu);
- if (stat & 0x10) {
+ if (stat & BIT(LOCAL_IRQ_MAILBOX0)) {
#ifdef CONFIG_SMP
void __iomem *mailbox0 = (intc.base +
LOCAL_MAILBOX0_CLR0 + 16 * cpu);
--
2.6.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 1/4] irqchip: bcm2836: Fix initialization of the LOCAL_IRQ_CNT*IRQ timers
The irqchip's register area includes the the setup for the timer's
scaling factors, and for the platform we want a fixed configuration of
these registers.
Signed-off-by: Eric Anholt
---
drivers/irqchip/irq-bcm2836.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index f687082..6ec125e 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -21,6 +21,9 @@
#include
#include
+#define LOCAL_CONTROL 0x000
+#define LOCAL_PRESCALER0x008
+
/*
* The low 2 bits identify the CPU that the GPU IRQ goes to, and the
* next 2 bits identify the CPU that the GPU FIQ goes to.
@@ -237,6 +240,27 @@ bcm2836_arm_irqchip_smp_init(void)
#endif
}
+/*
+ * The LOCAL_IRQ_CNT* timer firings are based off of the external
+ * oscillator with some scaling. The firmware sets up CNTFRQ to
+ * report 19.2Mhz, but doesn't set up the scaling registers.
+ */
+static void bcm2835_init_local_timer_frequency(void)
+{
+ /*
+* Set the timer to source from the 19.2Mhz crystal clock (bit
+* 8 unset), and only increment by 1 instead of 2 (bit 9
+* unset).
+*/
+ writel(0, intc.base + LOCAL_CONTROL);
+
+ /*
+* Set the timer prescaler to 1:1 (timer freq = input freq *
+* 2**31 / prescaler)
+*/
+ writel(0x8000, intc.base + LOCAL_PRESCALER);
+}
+
static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
struct device_node
*parent)
{
@@ -246,6 +270,8 @@ static int __init
bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
node->full_name);
}
+ bcm2835_init_local_timer_frequency();
+
intc.domain = irq_domain_add_linear(node, LAST_IRQ + 1,
_arm_irqchip_intc_ops,
NULL);
--
2.6.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 v2 0/8] Raspberry Pi 2 support.
Den 22.12.2015 20:01, skrev Eric Anholt: After finally booting the RPi2 I get several messages of: unexpected IRQ trap at vector 00 while typing _one_ character over uart. We were doing some debugging of that recently. It seems that every once in a while we get woken up but nothing shows up in the top-level status register. We need to just make the irqchip ignore instead of trying to look up a handler in that case, but I haven't prioritized it because it makes me worry that I'm just papering over a problem in our IRQ masking or something. I haven't seen any problems other than the printk, though. Downstream has this patch[1]: irq-bcm2836: Prevent spurious interrupts, and trap them early It has been used in the nightly build of OpenELEC[2] for 5 days now without any complaints (used with the downstream ARCH_BCM2709). [1] https://github.com/raspberrypi/linux/commit/688a5f2ada4fbd16547b574a17e6d359ab2364d0 [2] http://forum.kodi.tv/showthread.php?tid=250817=2192054#pid2192054 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Power management and ACPI fixes for v4.4-rc7
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-4.4-rc7 to receive power management and ACPI fixes for v4.4-rc7 with top-most commit 43b28ca8dfb07f2faa44204b3b3e7cb016468847 Merge branches 'acpi-processor' and 'pm-cpufreq' on top of commit 4ef7675344d687a0ef5b0d7c0cee12da005870c0 Linux 4.4-rc6 These fix an ACPI processor driver regression introduced during the 4.3 cycle and a mistake in the recently added SCPI support in the arm_big_little cpufreq driver. Specifics: - Fix a thermal management issue introduced by an ACPI processor driver change made during the 4.3 development cycle that failed to return 0 from a function on success which triggered an error cleanup path every time it had been called that deleted useful data structures created previously (Srinivas Pandruvada). - Fix a variable data type issue in the arm_big_little cpufreq driver's SCPI support code added recently that prevents error handling in there from working correctly (Dan Carpenter). Thanks! --- Dan Carpenter (1): cpufreq: scpi-cpufreq: signedness bug in scpi_get_dvfs_info() Srinivas Pandruvada (1): ACPI / processor: Fix thermal cooling device regression --- drivers/acpi/processor_driver.c | 3 ++- drivers/cpufreq/scpi-cpufreq.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpiolib: fix warning about iterator
On Sat, Dec 26, 2015 at 8:58 AM, Sudip Mukherjee wrote: > We were getting build warning about "iterator" being used uninitialized. > Use iterator properly to fix the build warning and in the process remove > the variable "pos" which is not required now. > > Signed-off-by: Sudip Mukherjee Aha there is a real patch solving the problem. Sorry Ross, had to drop your patch and replace it with this. Patch applied! Yours, Linus Walleij -- 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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 03:17:29PM -0600, Serge E. Hallyn wrote:
> On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote:
> > ptrace_has_cap() checks whether the current process should be
> > treated as having a certain capability for ptrace checks
> > against another process. Until now, this was equivalent to
> > has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
> >
> > However, if a root-owned process wants to enter a user
> > namespace for some reason without knowing who owns it and
> > therefore can't change to the namespace owner's uid and gid
> > before entering, as soon as it has entered the namespace,
> > the namespace owner can attach to it via ptrace and thereby
> > gain access to its uid and gid.
> >
> > While it is possible for the entering process to switch to
> > the uid of a claimed namespace owner before entering,
> > causing the attempt to enter to fail if the claimed uid is
> > wrong, this doesn't solve the problem of determining an
> > appropriate gid.
> >
> > With this change, the entering process can first enter the
> > namespace and then safely inspect the namespace's
> > properties, e.g. through /proc/self/{uid_map,gid_map},
> > assuming that the namespace owner doesn't have access to
> > uid 0.
> >
> > Changed in v2: The caller needs to be capable in the
> > namespace into which tcred's uids/gids can be mapped.
> >
> > Signed-off-by: Jann Horn
> > ---
> > kernel/ptrace.c | 33 -
> > 1 file changed, 28 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> > index b760bae..260a08d 100644
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -207,12 +208,34 @@ static int ptrace_check_attach(struct task_struct
> > *child, bool ignore_state)
> > return ret;
> > }
> >
> > -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> > +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> > {
> > + struct user_namespace *tns = tcred->user_ns;
> > +
> > + /* When a root-owned process enters a user namespace created by a
> > +* malicious user, the user shouldn't be able to execute code under
> > +* uid 0 by attaching to the root-owned process via ptrace.
> > +* Therefore, similar to the capable_wrt_inode_uidgid() check,
> > +* verify that all the uids and gids of the target process are
> > +* mapped into a namespace below the current one in which the caller
> > +* is capable.
> > +* No fsuid/fsgid check because __ptrace_may_access doesn't do it
> > +* either.
> > +*/
> > + while (
> > + !kuid_has_mapping(tns, tcred->euid) ||
> > + !kuid_has_mapping(tns, tcred->suid) ||
> > + !kuid_has_mapping(tns, tcred->uid) ||
> > + !kgid_has_mapping(tns, tcred->egid) ||
> > + !kgid_has_mapping(tns, tcred->sgid) ||
> > + !kgid_has_mapping(tns, tcred->gid)) {
> > + tns = tns->parent;
>
> Sorry, i can't quite remember - is there a way for a task in init_user_ns to
> have
> INVALID_UID | INVALID_GID ? I.e. any point in breaking here if tns ==
> _user_n?
I assumed that there isn't because the comment above the definition of
from_kuid()
says so. Checking... the syscalls for setting uid/gid seem to enforce that
uid/gid
aren't -1, and setuid/setgid executables require the uid/gid to be mapped. So it
seems to be true.
> > + }
> > +
> > if (mode & PTRACE_MODE_NOAUDIT)
> > - return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
> > + return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
> > else
> > - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> > + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
> > }
> >
> > /* Returns 0 on success, -errno on denial. */
> > @@ -241,7 +264,7 @@ static int __ptrace_may_access(struct task_struct
> > *task, unsigned int mode)
> > gid_eq(cred->gid, tcred->sgid) &&
> > gid_eq(cred->gid, tcred->gid))
> > goto ok;
> > - if (ptrace_has_cap(tcred->user_ns, mode))
> > + if (ptrace_has_cap(tcred, mode))
> > goto ok;
> > rcu_read_unlock();
> > return -EPERM;
> > @@ -252,7 +275,7 @@ ok:
> > dumpable = get_dumpable(task->mm);
> > rcu_read_lock();
> > if (dumpable != SUID_DUMP_USER &&
> > - !ptrace_has_cap(__task_cred(task)->user_ns, mode)) {
> > + !ptrace_has_cap(__task_cred(task), mode)) {
> > rcu_read_unlock();
> > return -EPERM;
> > }
> > --
> > 2.1.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
signature.asc
[PATCH v2 1/6] InfiniBand-ocrdma: One jump label less in ocrdma_alloc_ucontext_pd()
From: Markus Elfring
Date: Sat, 26 Dec 2015 22:18:38 +0100
This issue was detected by using the Coccinelle software.
* Let us return directly if a call of the _ocrdma_alloc_pd()
function failed.
* Reduce the scope for the local variable "status" to one case
of an if statement.
* Delete the jump label "err" then.
* Return zero as a constant at the end.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 583001b..7f10cc47 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -483,19 +483,16 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev
*dev,
struct ocrdma_ucontext *uctx,
struct ib_udata *udata)
{
- int status = 0;
-
uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata);
if (IS_ERR(uctx->cntxt_pd)) {
- status = PTR_ERR(uctx->cntxt_pd);
+ int status = PTR_ERR(uctx->cntxt_pd);
uctx->cntxt_pd = NULL;
- goto err;
+ return status;
}
uctx->cntxt_pd->uctx = uctx;
uctx->cntxt_pd->ibpd.device = >ibdev;
-err:
- return status;
+ return 0;
}
static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx)
--
2.6.3
--
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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote:
> ptrace_has_cap() checks whether the current process should be
> treated as having a certain capability for ptrace checks
> against another process. Until now, this was equivalent to
> has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
>
> However, if a root-owned process wants to enter a user
> namespace for some reason without knowing who owns it and
> therefore can't change to the namespace owner's uid and gid
> before entering, as soon as it has entered the namespace,
> the namespace owner can attach to it via ptrace and thereby
> gain access to its uid and gid.
>
> While it is possible for the entering process to switch to
> the uid of a claimed namespace owner before entering,
> causing the attempt to enter to fail if the claimed uid is
> wrong, this doesn't solve the problem of determining an
> appropriate gid.
>
> With this change, the entering process can first enter the
> namespace and then safely inspect the namespace's
> properties, e.g. through /proc/self/{uid_map,gid_map},
> assuming that the namespace owner doesn't have access to
> uid 0.
>
> Changed in v2: The caller needs to be capable in the
> namespace into which tcred's uids/gids can be mapped.
>
> Signed-off-by: Jann Horn
> ---
> kernel/ptrace.c | 33 -
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index b760bae..260a08d 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -207,12 +208,34 @@ static int ptrace_check_attach(struct task_struct
> *child, bool ignore_state)
> return ret;
> }
>
> -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> {
> + struct user_namespace *tns = tcred->user_ns;
> +
> + /* When a root-owned process enters a user namespace created by a
> + * malicious user, the user shouldn't be able to execute code under
> + * uid 0 by attaching to the root-owned process via ptrace.
> + * Therefore, similar to the capable_wrt_inode_uidgid() check,
> + * verify that all the uids and gids of the target process are
> + * mapped into a namespace below the current one in which the caller
> + * is capable.
> + * No fsuid/fsgid check because __ptrace_may_access doesn't do it
> + * either.
> + */
> + while (
> + !kuid_has_mapping(tns, tcred->euid) ||
> + !kuid_has_mapping(tns, tcred->suid) ||
> + !kuid_has_mapping(tns, tcred->uid) ||
> + !kgid_has_mapping(tns, tcred->egid) ||
> + !kgid_has_mapping(tns, tcred->sgid) ||
> + !kgid_has_mapping(tns, tcred->gid)) {
> + tns = tns->parent;
Sorry, i can't quite remember - is there a way for a task in init_user_ns to
have
INVALID_UID | INVALID_GID ? I.e. any point in breaking here if tns ==
_user_n?
> + }
> +
> if (mode & PTRACE_MODE_NOAUDIT)
> - return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
> + return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
> else
> - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
> }
>
> /* Returns 0 on success, -errno on denial. */
> @@ -241,7 +264,7 @@ static int __ptrace_may_access(struct task_struct *task,
> unsigned int mode)
> gid_eq(cred->gid, tcred->sgid) &&
> gid_eq(cred->gid, tcred->gid))
> goto ok;
> - if (ptrace_has_cap(tcred->user_ns, mode))
> + if (ptrace_has_cap(tcred, mode))
> goto ok;
> rcu_read_unlock();
> return -EPERM;
> @@ -252,7 +275,7 @@ ok:
> dumpable = get_dumpable(task->mm);
> rcu_read_lock();
> if (dumpable != SUID_DUMP_USER &&
> - !ptrace_has_cap(__task_cred(task)->user_ns, mode)) {
> + !ptrace_has_cap(__task_cred(task), mode)) {
> rcu_read_unlock();
> return -EPERM;
> }
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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/
Including Raspberry Pi -next trees in linux-next
I'll be sending pull-requests to Florian soon, but I would like to get my trees included in linux-next to get increased testing coverage of them against everything else going on for 4.5. I'm expecting to produce trees under these branch names for the forseeable future. Repo: https://github.com/anholt/linux.git branches: drm-vc4-next bcm2835-dt-next bcm2835-soc-next bcm2835-drivers-next bcm2385-defconfig-next (bcm2835-maintainers-next is a placeholder since we have nothing for it this round) signature.asc Description: PGP signature
Re: [PATCH] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 09:55:50PM +0100, Jann Horn wrote:
> On Sat, Dec 26, 2015 at 02:23:45PM -0600, Serge E. Hallyn wrote:
> > On Sat, Dec 26, 2015 at 02:10:38AM +0100, Jann Horn wrote:
> > > On Sat, Dec 12, 2015 at 09:12:41PM +0100, Jann Horn wrote:
> > > > With this change, the entering process can first enter the
> > > > namespace and then safely inspect the namespace's
> > > > properties, e.g. through /proc/self/{uid_map,gid_map},
> > > > assuming that the namespace owner doesn't have access to
> > > > uid 0.
> > >
> > > Actually, I think I missed something there. Well, at least it
> > > should not directly lead to a container escape.
> > >
> > >
> > > > -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> > > > +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> > > > {
> > > > + struct user_namespace *tns = tcred->user_ns;
> > > > + struct user_namespace *curns = current_cred()->user_ns;
> > > > +
> > > > + /* When a root-owned process enters a user namespace created by
> > > > a
> > > > +* malicious user, the user shouldn't be able to execute code
> > > > under
> > > > +* uid 0 by attaching to the root-owned process via ptrace.
> > > > +* Therefore, similar to the capable_wrt_inode_uidgid() check,
> > > > +* verify that all the uids and gids of the target process are
> > > > +* mapped into the current namespace.
> > > > +* No fsuid/fsgid check because __ptrace_may_access doesn't do
> > > > it
> > > > +* either.
> > > > +*/
> > > > + if (!kuid_has_mapping(curns, tcred->euid) ||
> > > > + !kuid_has_mapping(curns, tcred->suid) ||
> > > > + !kuid_has_mapping(curns, tcred->uid) ||
> > > > + !kgid_has_mapping(curns, tcred->egid) ||
> > > > + !kgid_has_mapping(curns, tcred->sgid) ||
> > > > + !kgid_has_mapping(curns, tcred->gid))
> > > > + return false;
> > > > +
> > > > if (mode & PTRACE_MODE_NOAUDIT)
> > > > - return has_ns_capability_noaudit(current, ns,
> > > > CAP_SYS_PTRACE);
> > > > + return has_ns_capability_noaudit(current, tns,
> > > > CAP_SYS_PTRACE);
> > > > else
> > > > - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> > > > + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
> > > > }
> > >
> > > If the namespace owner can run code in the init namespace, the kuids are
> > > mapped into curns but he is still capable wrt the target namespace.
> > >
> > > I think a proper fix should first determine the highest parent of
> > > tcred->user_ns in which the caller still has privs, then do the
> > > kxid_has_mapping() checks in there.
> >
> > Hi,
> >
> > I don't quite follow what you are concerned about. Based on the new
> > patch you sent, I assume it's not the case where the tcred's kuid is
> > actually mapped into the container. So is it the case where I
> > unshare a userns which unshares a userns, then setns from the grandparent
> > into the child? And if so, the concern is that if the setns()ing task's
> > kuid is mappable all along into the grandhild, then container root should
> > be able to ptrace it?
>
> Consider the following scenario:
>
> init_user_ns has a child namespace (I'll call it child_ns).
> child_ns is owned by an attacker (child_ns->owner == attacker_kuid).
> The attacking process has current_cred()->euid == attacker_kuid and lives
> in init_user_ns (which means it's capable in child_ns).
Ah, right. Special.
Thanks.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
The error return value of platform_get_irq seems to often get dropped.
Signed-off-by: Julia Lawall
---
v2: Check for the direct return case also. Added some mailing lists of
common offenders.
diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..44680d0
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,58 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0, but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+//
+
+@r depends on context || org || report@
+constant C;
+statement S;
+expression e, ret;
+position j0, j1;
+@@
+
+* e@j0 = platform_get_irq(...);
+(
+if@j1 (...) {
+ ...
+ return -C;
+} else S
+|
+if@j1 (...) {
+ ...
+ ret = -C;
+ ...
+ return ret;
+} else S
+)
+
+//
+
+@script:python r_org depends on org@
+j0 << r.j0;
+j1 << r.j1;
+@@
+
+msg = "Propagate return value of platform_get_irq."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+
+//
+
+@script:python r_report depends on report@
+j0 << r.j0;
+j1 << r.j1;
+@@
+
+msg = "Propagate return value of platform_get_irq around line %s." %
(j1[0].line)
+coccilib.report.print_report(j0[0], msg)
+
--
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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 02:23:45PM -0600, Serge E. Hallyn wrote:
> On Sat, Dec 26, 2015 at 02:10:38AM +0100, Jann Horn wrote:
> > On Sat, Dec 12, 2015 at 09:12:41PM +0100, Jann Horn wrote:
> > > With this change, the entering process can first enter the
> > > namespace and then safely inspect the namespace's
> > > properties, e.g. through /proc/self/{uid_map,gid_map},
> > > assuming that the namespace owner doesn't have access to
> > > uid 0.
> >
> > Actually, I think I missed something there. Well, at least it
> > should not directly lead to a container escape.
> >
> >
> > > -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> > > +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> > > {
> > > + struct user_namespace *tns = tcred->user_ns;
> > > + struct user_namespace *curns = current_cred()->user_ns;
> > > +
> > > + /* When a root-owned process enters a user namespace created by a
> > > + * malicious user, the user shouldn't be able to execute code under
> > > + * uid 0 by attaching to the root-owned process via ptrace.
> > > + * Therefore, similar to the capable_wrt_inode_uidgid() check,
> > > + * verify that all the uids and gids of the target process are
> > > + * mapped into the current namespace.
> > > + * No fsuid/fsgid check because __ptrace_may_access doesn't do it
> > > + * either.
> > > + */
> > > + if (!kuid_has_mapping(curns, tcred->euid) ||
> > > + !kuid_has_mapping(curns, tcred->suid) ||
> > > + !kuid_has_mapping(curns, tcred->uid) ||
> > > + !kgid_has_mapping(curns, tcred->egid) ||
> > > + !kgid_has_mapping(curns, tcred->sgid) ||
> > > + !kgid_has_mapping(curns, tcred->gid))
> > > + return false;
> > > +
> > > if (mode & PTRACE_MODE_NOAUDIT)
> > > - return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
> > > + return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
> > > else
> > > - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> > > + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
> > > }
> >
> > If the namespace owner can run code in the init namespace, the kuids are
> > mapped into curns but he is still capable wrt the target namespace.
> >
> > I think a proper fix should first determine the highest parent of
> > tcred->user_ns in which the caller still has privs, then do the
> > kxid_has_mapping() checks in there.
>
> Hi,
>
> I don't quite follow what you are concerned about. Based on the new
> patch you sent, I assume it's not the case where the tcred's kuid is
> actually mapped into the container. So is it the case where I
> unshare a userns which unshares a userns, then setns from the grandparent
> into the child? And if so, the concern is that if the setns()ing task's
> kuid is mappable all along into the grandhild, then container root should
> be able to ptrace it?
Consider the following scenario:
init_user_ns has a child namespace (I'll call it child_ns).
child_ns is owned by an attacker (child_ns->owner == attacker_kuid).
The attacking process has current_cred()->euid == attacker_kuid and lives
in init_user_ns (which means it's capable in child_ns).
The victim process (with euid==0) enters the namespace, then the attacking
process tries to attach to it. ptrace_has_cap(tcred, mode) would, with my
old patch, still be true because current is capable in tcred->user_ns and
all kuids are mapped into init_user_ns.
The new patch uses the following rule for cap checks:
The caller is capable relative to a target if a user namespace exists
for which all of the following conditions are true:
- The caller has the requested capability inside the namespace.
- The target is inside the namespace (either directly or in a child).
- The target's kuids and kgids are mapped into the namespace.
The first rule is enforced by the has_ns_capability(..., tns, ...) or
has_ns_capability_noaudit(..., tns, ...) call at the bottom.
The second rule is implicitly true because tns initially is the target's
user namespace and then moves up through ->parent.
The third rule is enforced by the while loop.
This prevents the attack I described, but e.g. still allows someone who
is capable in init_user_ns to ptrace anything, no matter in what weird
namespace the target is - if a task was ptrace-able for a process before
it called clone(CLONE_NEWUSER) / unshare(CLONE_NEWUSER) /
setns(, CLONE_NEWUSER), it should still be ptrace-able afterwards.
(Unless access was permitted based on the introspection rule.)
signature.asc
Description: Digital signature
Re: [PATCH] coccinelle: api: check for propagation of error from platform_get_irq
On Sat, 26 Dec 2015, Sergei Shtylyov wrote: > On 12/26/2015 11:24 PM, Julia Lawall wrote: > > > The conclusion seems to be that it is useful to override the value, so we > > can just drop this semantic patch. > >No! As I said, unconditionally overriding an error value breaks the > deferred probing. It's actually a bug to override it, so the patch seems > *very* useful. Ah, OK, I'll send an improved version then :) julia -- 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] coccinelle: api: check for propagation of error from platform_get_irq
On 12/26/2015 11:24 PM, Julia Lawall wrote: The conclusion seems to be that it is useful to override the value, so we can just drop this semantic patch. No! As I said, unconditionally overriding an error value breaks the deferred probing. It's actually a bug to override it, so the patch seems *very* useful. julia MBR, Sergei -- 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] coccinelle: api: check for propagation of error from platform_get_irq
The conclusion seems to be that it is useful to override the value, so we can just drop this semantic patch. julia -- 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] ptrace: being capable wrt a process requires mapped uids/gids
On Sat, Dec 26, 2015 at 02:10:38AM +0100, Jann Horn wrote:
> On Sat, Dec 12, 2015 at 09:12:41PM +0100, Jann Horn wrote:
> > With this change, the entering process can first enter the
> > namespace and then safely inspect the namespace's
> > properties, e.g. through /proc/self/{uid_map,gid_map},
> > assuming that the namespace owner doesn't have access to
> > uid 0.
>
> Actually, I think I missed something there. Well, at least it
> should not directly lead to a container escape.
>
>
> > -static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
> > +static bool ptrace_has_cap(const struct cred *tcred, unsigned int mode)
> > {
> > + struct user_namespace *tns = tcred->user_ns;
> > + struct user_namespace *curns = current_cred()->user_ns;
> > +
> > + /* When a root-owned process enters a user namespace created by a
> > +* malicious user, the user shouldn't be able to execute code under
> > +* uid 0 by attaching to the root-owned process via ptrace.
> > +* Therefore, similar to the capable_wrt_inode_uidgid() check,
> > +* verify that all the uids and gids of the target process are
> > +* mapped into the current namespace.
> > +* No fsuid/fsgid check because __ptrace_may_access doesn't do it
> > +* either.
> > +*/
> > + if (!kuid_has_mapping(curns, tcred->euid) ||
> > + !kuid_has_mapping(curns, tcred->suid) ||
> > + !kuid_has_mapping(curns, tcred->uid) ||
> > + !kgid_has_mapping(curns, tcred->egid) ||
> > + !kgid_has_mapping(curns, tcred->sgid) ||
> > + !kgid_has_mapping(curns, tcred->gid))
> > + return false;
> > +
> > if (mode & PTRACE_MODE_NOAUDIT)
> > - return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
> > + return has_ns_capability_noaudit(current, tns, CAP_SYS_PTRACE);
> > else
> > - return has_ns_capability(current, ns, CAP_SYS_PTRACE);
> > + return has_ns_capability(current, tns, CAP_SYS_PTRACE);
> > }
>
> If the namespace owner can run code in the init namespace, the kuids are
> mapped into curns but he is still capable wrt the target namespace.
>
> I think a proper fix should first determine the highest parent of
> tcred->user_ns in which the caller still has privs, then do the
> kxid_has_mapping() checks in there.
Hi,
I don't quite follow what you are concerned about. Based on the new
patch you sent, I assume it's not the case where the tcred's kuid is
actually mapped into the container. So is it the case where I
unshare a userns which unshares a userns, then setns from the grandparent
into the child? And if so, the concern is that if the setns()ing task's
kuid is mappable all along into the grandhild, then container root should
be able to ptrace it?
thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] drivers: net: cpsw: fix error return code
On 12/26/2015 11:07 PM, Julia Lawall wrote:
diff --git a/drivers/net/ethernet/ti/cpsw.c
b/drivers/net/ethernet/ti/cpsw.c
index 3409e80..6a76992 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device
*pdev)
/* RX IRQ */
irq = platform_get_irq(pdev, 1);
-if (irq < 0)
+if (irq < 0) {
+ret = -ENOENT;
Why not just propagate an error returned by that function?
OK, I did what was done a few lines before in the same function:
ndev->irq = platform_get_irq(pdev, 1);
if (ndev->irq < 0) {
dev_err(priv->dev, "error getting irq resource\n");
ret = -ENOENT;
goto clean_ale_ret;
}
Maybe they should all be changed?
Yeah, I'd vote for it. I'm seeing no sense in overriding an actual
error.
Hm, I decided to check drivers/base/dd.c and I think I maybe know the
reason now: -ENXIO, usually returned by platform_get_irq(), is silently
"swallowed" by really_probe(); to be precise, -ENODEV and -ENXIO are only
reported with pr_debug(), while -ENOENT causes printk(KERN_WARNING, ...)...
Sorry, I'm confused... What should it be? v1 or v2? Here are the counts
of the different constants returned on failure of platform_get_irq:
I was somewhat confused myself but then I remembered about the deferred
probing -- overriding error code basically just disables it in this case.
ENODEV: 84
ENXIO: 67
Those 2 totally make no sense. :-)
EINVAL: 61
ENOENT: 29
EBUSY: 11
Hm...
EIO: 2
EPROBE_DEFER: 1
Hm, and that last one is unconditional?
julia
MBR, Sergei
--
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] coccinelle: api: check for propagation of error from platform_get_irq
On Sat, 26 Dec 2015, Sergei Shtylyov wrote: > On 12/26/2015 10:24 PM, Julia Lawall wrote: > > > The error return value of platform_get_irq seems to often get dropped. > >Maybe it was intentional (see my recent follow-up to your netdev patch). > But if an error gets unconditionally overriden, deferred probing can't work. > So your patches seem good things in the end. Thank you! Actually, this semantic patch overloos the case where a constant is returned directly, which is apparently also popular. I can update this if the whole concept is useful, but that's not clear at the moment... julia -- 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 6/7] drivers: net: cpsw: fix error return code
On Sat, 26 Dec 2015, Sergei Shtylyov wrote:
> Hello.
>
> On 12/26/2015 08:50 PM, Sergei Shtylyov wrote:
>
> > > > > diff --git a/drivers/net/ethernet/ti/cpsw.c
> > > > > b/drivers/net/ethernet/ti/cpsw.c
> > > > > index 3409e80..6a76992 100644
> > > > > --- a/drivers/net/ethernet/ti/cpsw.c
> > > > > +++ b/drivers/net/ethernet/ti/cpsw.c
> > > > > @@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device
> > > > > *pdev)
> > > > >
> > > > >/* RX IRQ */
> > > > >irq = platform_get_irq(pdev, 1);
> > > > > -if (irq < 0)
> > > > > +if (irq < 0) {
> > > > > +ret = -ENOENT;
> > > >
> > > > Why not just propagate an error returned by that function?
> > >
> > > OK, I did what was done a few lines before in the same function:
> > >
> > > ndev->irq = platform_get_irq(pdev, 1);
> > > if (ndev->irq < 0) {
> > > dev_err(priv->dev, "error getting irq resource\n");
> > > ret = -ENOENT;
> > > goto clean_ale_ret;
> > > }
> > >
> > > Maybe they should all be changed?
> >
> > Yeah, I'd vote for it. I'm seeing no sense in overriding an actual
> > error.
>
>Hm, I decided to check drivers/base/dd.c and I think I maybe know the
> reason now: -ENXIO, usually returned by platform_get_irq(), is silently
> "swallowed" by really_probe(); to be precise, -ENODEV and -ENXIO are only
> reported with pr_debug(), while -ENOENT causes printk(KERN_WARNING, ...)...
Sorry, I'm confused... What should it be? v1 or v2? Here are the counts
of the different constants returned on failure of platform_get_irq:
ENODEV: 84
ENXIO: 67
EINVAL: 61
ENOENT: 29
EBUSY: 11
EIO: 2
EPROBE_DEFER: 1
julia
--
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] coccinelle: api: check for propagation of error from platform_get_irq
On 12/26/2015 10:24 PM, Julia Lawall wrote: The error return value of platform_get_irq seems to often get dropped. Maybe it was intentional (see my recent follow-up to your netdev patch). But if an error gets unconditionally overriden, deferred probing can't work. So your patches seem good things in the end. Thank you! Signed-off-by: Julia Lawall [...] MBR, Sergei -- 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 6/7] drivers: net: cpsw: fix error return code
Hello.
On 12/26/2015 08:50 PM, Sergei Shtylyov wrote:
diff --git a/drivers/net/ethernet/ti/cpsw.c
b/drivers/net/ethernet/ti/cpsw.c
index 3409e80..6a76992 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
/* RX IRQ */
irq = platform_get_irq(pdev, 1);
-if (irq < 0)
+if (irq < 0) {
+ret = -ENOENT;
Why not just propagate an error returned by that function?
OK, I did what was done a few lines before in the same function:
ndev->irq = platform_get_irq(pdev, 1);
if (ndev->irq < 0) {
dev_err(priv->dev, "error getting irq resource\n");
ret = -ENOENT;
goto clean_ale_ret;
}
Maybe they should all be changed?
Yeah, I'd vote for it. I'm seeing no sense in overriding an actual error.
Hm, I decided to check drivers/base/dd.c and I think I maybe know the
reason now: -ENXIO, usually returned by platform_get_irq(), is silently
"swallowed" by really_probe(); to be precise, -ENODEV and -ENXIO are only
reported with pr_debug(), while -ENOENT causes printk(KERN_WARNING, ...)...
[...]
julia
MBR, Sergei
--
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/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd()
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
Hi Markus,
[auto build test WARNING on v4.4-rc6]
[also build test WARNING on next-20151223]
url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/InfiniBand-ocrdma-Fine-tuning-for-some-function-implementations/20151227-025304
coccinelle warnings: (new ones prefixed by >>)
>> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:489:9-16: ERROR: PTR_ERR applied
>> after initialization to constant on line 488
vim +489 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
482 static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev *dev,
483 struct ocrdma_ucontext *uctx,
484 struct ib_udata *udata)
485 {
486 uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata);
487 if (IS_ERR(uctx->cntxt_pd)) {
> 488 uctx->cntxt_pd = NULL;
> 489 return PTR_ERR(uctx->cntxt_pd);
490 }
491
492 uctx->cntxt_pd->uctx = uctx;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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] coccinelle: api: check for propagation of error from platform_get_irq
The error return value of platform_get_irq seems to often get dropped.
Signed-off-by: Julia Lawall
---
scripts/coccinelle/api/platform_get_irq_return.cocci | 53 ++
1 file changed, 53 insertions(+)
diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..96fc560
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,53 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0, but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+//
+
+@r depends on context || org || report@
+constant C;
+expression e, ret;
+position j0, j1, j2;
+@@
+
+* e@j0 = platform_get_irq(...);
+if (...) {
+ ...
+ ret@j1 = -C;
+ ...
+ return ret@j2;
+}
+
+//
+
+@script:python r_org depends on org@
+j0 << r.j0;
+j1 << r.j1;
+j2 << r.j2;
+@@
+
+msg = "Propagate return value of platform_get_irq."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+coccilib.org.print_link(j2[0], "")
+
+//
+
+@script:python r_report depends on report@
+j0 << r.j0;
+j1 << r.j1;
+j2 << r.j2;
+@@
+
+msg = "Propagate return value of platform_get_irq around lines %s,%s." %
(j1[0].line,j2[0].line)
+coccilib.report.print_report(j0[0], msg)
+
--
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: i2c-core: One function call less in acpi_i2c_space_handler() after error detection
>> I would appreciate if an unnecessary function call can be avoided here >> so that the affected exception handling can become also a bit more efficient. > > Simpler code is easier to maintain. There are different opinions available around the desired simplicity. > See your patch, you didn't get it correctly at your first try. I wonder myself about the circumstances on how my incomplete update suggestion did happen. > Also, this is not a hot path, I'm curious if approaches around better exception handling can eventually become a "hot topic". > so I see it as a micro-optimization I can agree to this view for this function implementation. > also adding complexity. There are the usual software development trade-offs. > I don't favor that. Thanks for your constructive feedback. Is an identifier like "free_client" a bit nicer (according to the Linux coding style recommendations) than the short jump label "err" in the discussed use case? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7 v2] drivers: net: cpsw: fix error return code
Propagate the return value of platform_get_irq on failure.
A simplified version of the semantic match that finds the two cases where
no error code is returned at all is as follows:
(http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
v2: propagate platform_get_irq return value, at all calls
drivers/net/ethernet/ti/cpsw.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 3409e80..34ce7dc 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2427,7 +2427,7 @@ static int cpsw_probe(struct platform_device *pdev)
ndev->irq = platform_get_irq(pdev, 1);
if (ndev->irq < 0) {
dev_err(priv->dev, "error getting irq resource\n");
- ret = -ENOENT;
+ ret = ndev->irq;
goto clean_ale_ret;
}
@@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
/* RX IRQ */
irq = platform_get_irq(pdev, 1);
- if (irq < 0)
+ if (irq < 0) {
+ ret = irq;
goto clean_ale_ret;
+ }
priv->irqs_table[0] = irq;
ret = devm_request_irq(>dev, irq, cpsw_rx_interrupt,
@@ -2461,8 +2463,10 @@ static int cpsw_probe(struct platform_device *pdev)
/* TX IRQ */
irq = platform_get_irq(pdev, 2);
- if (irq < 0)
+ if (irq < 0) {
+ ret = irq;
goto clean_ale_ret;
+ }
priv->irqs_table[1] = irq;
ret = devm_request_irq(>dev, irq, cpsw_tx_interrupt,
--
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 6/6] InfiniBand-ocrdma: Delete an unnecessary variable in ocrdma_dealloc_pd()
From: Markus Elfring
Date: Sat, 26 Dec 2015 19:09:23 +0100
1. Return zero in one case directly.
2. Return the value from a call of the _ocrdma_dealloc_pd() function
without using an extra assignment for the local variable.
3. Remove the variable "status" in this function then.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 7bedf44..0f79a01 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -750,7 +750,6 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd)
struct ocrdma_pd *pd = get_ocrdma_pd(ibpd);
struct ocrdma_dev *dev = get_ocrdma_dev(ibpd->device);
struct ocrdma_ucontext *uctx = NULL;
- int status = 0;
u64 usr_db;
uctx = pd->uctx;
@@ -764,11 +763,10 @@ int ocrdma_dealloc_pd(struct ib_pd *ibpd)
if (is_ucontext_pd(uctx, pd)) {
ocrdma_release_ucontext_pd(uctx);
- return status;
+ return 0;
}
}
- status = _ocrdma_dealloc_pd(dev, pd);
- return status;
+ return _ocrdma_dealloc_pd(dev, pd);
}
static int ocrdma_alloc_lkey(struct ocrdma_dev *dev, struct ocrdma_mr *mr,
--
2.6.3
--
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] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver
On Sat 2015-12-26 00:32:25, Pali Rohár wrote: > Driver for omap3 with documentation is there since v4.4-rc1. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek Tested-by: Pavel Machek Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_resize_cq()
From: Markus Elfring
Date: Sat, 26 Dec 2015 18:54:47 +0100
Return constant integer values without storing them in the local
variable "status".
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 2de39d3..7bedf44 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -1120,15 +1120,12 @@ ctx_err:
int ocrdma_resize_cq(struct ib_cq *ibcq, int new_cnt,
struct ib_udata *udata)
{
- int status = 0;
struct ocrdma_cq *cq = get_ocrdma_cq(ibcq);
- if (new_cnt < 1 || new_cnt > cq->max_hw_cqe) {
- status = -EINVAL;
- return status;
- }
+ if (new_cnt < 1 || new_cnt > cq->max_hw_cqe)
+ return -EINVAL;
ibcq->cqe = new_cnt;
- return status;
+ return 0;
}
static void ocrdma_flush_cq(struct ocrdma_cq *cq)
--
2.6.3
--
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/6] InfiniBand-ocrdma: Return a value from a function call in _ocrdma_modify_qp() directly
From: Markus Elfring Date: Sat, 26 Dec 2015 18:40:43 +0100 Return the value from a call of the ocrdma_mbx_modify_qp() function without using an extra assignment for the local variable "status". Signed-off-by: Markus Elfring --- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c index aba1b5a..2de39d3 100644 --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c @@ -1491,9 +1491,7 @@ int _ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, */ if (status < 0) return status; - status = ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); - - return status; + return ocrdma_mbx_modify_qp(dev, qp, attr, attr_mask); } int ocrdma_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, -- 2.6.3 -- 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 3/6] InfiniBand-ocrdma: Returning only value constants in ocrdma_qp_state_change()
From: Markus Elfring
Date: Sat, 26 Dec 2015 18:28:35 +0100
Return zero at the end without using the local variable "status".
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index 6647aa6..9a2b153 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -2110,7 +2110,6 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum
ib_qp_state new_ib_state,
enum ib_qp_state *old_ib_state)
{
unsigned long flags;
- int status = 0;
enum ocrdma_qp_state new_state;
new_state = get_ocrdma_qp_state(new_ib_state);
@@ -2135,7 +2134,7 @@ int ocrdma_qp_state_change(struct ocrdma_qp *qp, enum
ib_qp_state new_ib_state,
qp->state = new_state;
spin_unlock_irqrestore(>q_lock, flags);
- return status;
+ return 0;
}
static u32 ocrdma_set_create_qp_mbx_access_flags(struct ocrdma_qp *qp)
--
2.6.3
--
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/6] InfiniBand-ocrdma: Delete unnecessary variable initialisations in 11 functions
From: Markus Elfring
Date: Sat, 26 Dec 2015 18:18:18 +0100
The variable "status" will be set to an appropriate value a bit later.
Thus let us omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/ocrdma/ocrdma_ah.c| 2 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c| 4 ++--
drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 ++--
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 12 ++--
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
index 9820074..98c0abd 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_ah.c
@@ -59,7 +59,7 @@ static inline int set_av_attr(struct ocrdma_dev *dev, struct
ocrdma_ah *ah,
struct ib_ah_attr *attr, union ib_gid *sgid,
int pdid, bool *isvlan, u16 vlan_tag)
{
- int status = 0;
+ int status;
struct ocrdma_eth_vlan eth;
struct ocrdma_grh grh;
int eth_sz;
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index 30f67be..6647aa6 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -1089,7 +1089,7 @@ mbx_err:
static int ocrdma_nonemb_mbx_cmd(struct ocrdma_dev *dev, struct ocrdma_mqe
*mqe,
void *payload_va)
{
- int status = 0;
+ int status;
struct ocrdma_mbx_rsp *rsp = payload_va;
if ((mqe->hdr.spcl_sge_cnt_emb & OCRDMA_MQE_HDR_EMB_MASK) >>
@@ -2842,7 +2842,7 @@ int ocrdma_mbx_destroy_srq(struct ocrdma_dev *dev, struct
ocrdma_srq *srq)
static int ocrdma_mbx_get_dcbx_config(struct ocrdma_dev *dev, u32 ptype,
struct ocrdma_dcbx_cfg *dcbxcfg)
{
- int status = 0;
+ int status;
dma_addr_t pa;
struct ocrdma_mqe cmd;
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
index 86c303a..119baa3 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c
@@ -608,7 +608,7 @@ static char *ocrdma_driver_dbg_stats(struct ocrdma_dev *dev)
static void ocrdma_update_stats(struct ocrdma_dev *dev)
{
ulong now = jiffies, secs;
- int status = 0;
+ int status;
struct ocrdma_rdma_stats_resp *rdma_stats =
(struct ocrdma_rdma_stats_resp *)dev->stats_mem.va;
struct ocrdma_rsrc_stats *rsrc_stats = _stats->act_rsrc_stats;
@@ -639,7 +639,7 @@ static ssize_t ocrdma_dbgfs_ops_write(struct file *filp,
{
char tmp_str[32];
long reset;
- int status = 0;
+ int status;
struct ocrdma_stats *pstats = filp->private_data;
struct ocrdma_dev *dev = pstats->dev;
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 374c839..aba1b5a 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -419,7 +419,7 @@ static struct ocrdma_pd *_ocrdma_alloc_pd(struct ocrdma_dev
*dev,
struct ib_udata *udata)
{
struct ocrdma_pd *pd = NULL;
- int status = 0;
+ int status;
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd)
@@ -468,7 +468,7 @@ static inline int is_ucontext_pd(struct ocrdma_ucontext
*uctx,
static int _ocrdma_dealloc_pd(struct ocrdma_dev *dev,
struct ocrdma_pd *pd)
{
- int status = 0;
+ int status;
if (dev->pd_mgr->pd_prealloc_valid)
status = ocrdma_put_pd_num(dev, pd->id, pd->dpp_enabled);
@@ -592,7 +592,7 @@ map_err:
int ocrdma_dealloc_ucontext(struct ib_ucontext *ibctx)
{
- int status = 0;
+ int status;
struct ocrdma_mm *mm, *tmp;
struct ocrdma_ucontext *uctx = get_ocrdma_ucontext(ibctx);
struct ocrdma_dev *dev = get_ocrdma_dev(ibctx->device);
@@ -619,7 +619,7 @@ int ocrdma_mmap(struct ib_ucontext *context, struct
vm_area_struct *vma)
unsigned long vm_page = vma->vm_pgoff << PAGE_SHIFT;
u64 unmapped_db = (u64) dev->nic_info.unmapped_db;
unsigned long len = (vma->vm_end - vma->vm_start);
- int status = 0;
+ int status;
bool found;
if (vma->vm_start & (PAGE_SIZE - 1))
@@ -1282,7 +1282,7 @@ static int ocrdma_copy_qp_uresp(struct ocrdma_qp *qp,
struct ib_udata *udata, int dpp_offset,
int dpp_credit_lmt, int srq)
{
- int status = 0;
+ int status;
u64 usr_db;
struct ocrdma_create_qp_uresp uresp;
struct ocrdma_pd *pd = qp->pd;
@@ -1946,7 +1946,7 @@ int ocrdma_modify_srq(struct ib_srq *ibsrq,
enum ib_srq_attr_mask srq_attr_mask,
[PATCH 1/6] InfiniBand-ocrdma: One variable and jump label less in ocrdma_alloc_ucontext_pd()
From: Markus Elfring
Date: Sat, 26 Dec 2015 17:16:00 +0100
This issue was detected by using the Coccinelle software.
* Let us return directly if a call of the _ocrdma_alloc_pd()
function failed.
* Delete the jump label "err" and the local variable "status" then.
Signed-off-by: Markus Elfring
---
drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 583001b..374c839 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -483,19 +483,15 @@ static int ocrdma_alloc_ucontext_pd(struct ocrdma_dev
*dev,
struct ocrdma_ucontext *uctx,
struct ib_udata *udata)
{
- int status = 0;
-
uctx->cntxt_pd = _ocrdma_alloc_pd(dev, uctx, udata);
if (IS_ERR(uctx->cntxt_pd)) {
- status = PTR_ERR(uctx->cntxt_pd);
uctx->cntxt_pd = NULL;
- goto err;
+ return PTR_ERR(uctx->cntxt_pd);
}
uctx->cntxt_pd->uctx = uctx;
uctx->cntxt_pd->ibpd.device = >ibdev;
-err:
- return status;
+ return 0;
}
static int ocrdma_dealloc_ucontext_pd(struct ocrdma_ucontext *uctx)
--
2.6.3
--
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: i2c-core: One function call less in acpi_i2c_space_handler() after error detection
On Sat, Dec 26, 2015 at 09:52:11AM +0100, SF Markus Elfring wrote: > >> The kfree() function was called in one case by the > >> acpi_i2c_space_handler() function during error handling > >> even if the passed variable "client" contained a null pointer. > > > > This is OK. kfree() is known to be NULL-tolerant and we rely on it in > > various places to keep the code simpler. > > I would appreciate if an unnecessary function call can be avoided here > so that the affected exception handling can become also a bit more efficient. Simpler code is easier to maintain. See your patch, you didn't get it correctly at your first try. Also, this is not a hot path, so I see it as a micro-optimization also adding complexity. I don't favor that. signature.asc Description: PGP signature
[PATCH 0/6] InfiniBand-ocrdma: Fine-tuning for some function implementations
From: Markus Elfring Date: Sat, 26 Dec 2015 19:30:54 +0100 Several update suggestions were taken into account from static source code analysis. Markus Elfring (6): One variable and jump label less in ocrdma_alloc_ucontext_pd() Delete unnecessary variable initialisations in 11 functions Returning only value constants in ocrdma_qp_state_change() Return a value from a function call in _ocrdma_modify_qp() directly Returning only value constants in ocrdma_resize_cq() Delete an unnecessary variable in ocrdma_dealloc_pd() drivers/infiniband/hw/ocrdma/ocrdma_ah.c| 2 +- drivers/infiniband/hw/ocrdma/ocrdma_hw.c| 7 +++--- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 4 +-- drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 39 +++-- 4 files changed, 20 insertions(+), 32 deletions(-) -- 2.6.3 -- 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: add start and size to ABI documentation
Document the start and size fields (which were introduced in commit v2.5.42-215-gb288f6a) to avoid guesswork on the unit. Signed-off-by: Peter Wu --- Hi, As the meaning has not changed for over 13 years, I would like to formalize these attributes such that users can rely on it[1][2]. The sector definition was inspired by the block/stat.txt documentation. By the way, the ABI/README document is ambiguous on the meaning of "Date", is it the creation date of the documentation entry or the creation of the filesystem interface? I have chosen the latter here. Kind regards, Peter [1]: https://lkml.kernel.org/r/201012011729.18661.li...@egidy.de [2]: https://unix.stackexchange.com/questions/52215/determine-the-size-of-a-block-device#comment112867_52219 --- Documentation/ABI/testing/sysfs-block | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 71d184d..b85a266 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -235,3 +235,20 @@ Description: write_same_max_bytes is 0, write same is not supported by the device. +What: /sys/block///start +Date: October 2002 +Contact: linux-bl...@vger.kernel.org +Kernel Version:2.5.43 +Description: + Starting position of the partition within the disk. + Measured in standard UNIX 512-byte sectors (not a + device-specific block size). + +What: /sys/block///size +Date: October 2002 +Contact: linux-bl...@vger.kernel.org +Kernel Version:2.5.43 +Description: + Size of the partition in standard UNIX 512-byte sectors + (not a device-specific block size). + -- 2.6.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] Fix documentation for adp1653 DT
On Sat 2015-12-26 00:37:16, Pali Rohár wrote: > Property names do not match real names needed by driver itself. > This patch fix this problem. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek Now... if someone could convert adp1653 to the LED subsystem so this is testable from the shell... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: n900: Include adp1653 device
On Sat 2015-12-26 00:40:12, Pali Rohár wrote: > This patch adds adp1653 device into n900 DT structure. DT support in > adp1653 driver is there since v4.2-rc1 version. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nvme: consolidate kmallc + memset 0 into kzalloc
This is an API consolidation only. The use of kmalloc + memset to 0 here should be equivalent to kzalloc. Signed-off-by: Nicholas Mc Guire --- Found by coccinelle script (relaxed version of scripts/coccinelle/api/alloc/kzalloc-simple.cocci) Patch was compile tested with: x86_64_defconfig CONFIG_BLK_DEV_NVME=m Patch is against linux-next (localversion-next is -next-20151222) drivers/nvme/host/scsi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/nvme/host/scsi.c b/drivers/nvme/host/scsi.c index e947e29..8f447e3 100644 --- a/drivers/nvme/host/scsi.c +++ b/drivers/nvme/host/scsi.c @@ -715,7 +715,7 @@ static int nvme_trans_ext_inq_page(struct nvme_ns *ns, struct sg_io_hdr *hdr, u8 v_sup; u8 luiclr = 0x01; - inq_response = kmalloc(EXTENDED_INQUIRY_DATA_PAGE_LENGTH, GFP_KERNEL); + inq_response = kzalloc(EXTENDED_INQUIRY_DATA_PAGE_LENGTH, GFP_KERNEL); if (inq_response == NULL) return -ENOMEM; @@ -743,7 +743,6 @@ static int nvme_trans_ext_inq_page(struct nvme_ns *ns, struct sg_io_hdr *hdr, v_sup = id_ctrl->vwc; kfree(id_ctrl); - memset(inq_response, 0, EXTENDED_INQUIRY_DATA_PAGE_LENGTH); inq_response[1] = INQ_EXTENDED_INQUIRY_DATA_PAGE;/* Page Code */ inq_response[2] = 0x00;/* Page Length MSB */ inq_response[3] = 0x3C;/* Page Length LSB */ -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] fix a dead loop when in heavy low memory
On Sun, Dec 27, 2015 at 03:39:42AM +0800, Figo wrote: > Android System UI hang when run heavy monkey stress test. What changed from v1 of this patch? Please describe that below the --- line. > > Signed-off-by: Figo I need a "full" name here, not a "short" name, sorry, before I can do anything with this patch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] IDE-ACPI: Fine-tuning for a function
IDE is in deep freeze maintainence mode. Therefore patches that perform simplications and cleanups will not be accepted. 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/
Re: [PATCH 6/7] drivers: net: cpsw: fix error return code
On 12/26/2015 8:40 PM, Julia Lawall wrote:
diff --git a/drivers/net/ethernet/ti/cpsw.c
b/drivers/net/ethernet/ti/cpsw.c
index 3409e80..6a76992 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
/* RX IRQ */
irq = platform_get_irq(pdev, 1);
- if (irq < 0)
+ if (irq < 0) {
+ ret = -ENOENT;
Why not just propagate an error returned by that function?
OK, I did what was done a few lines before in the same function:
ndev->irq = platform_get_irq(pdev, 1);
if (ndev->irq < 0) {
dev_err(priv->dev, "error getting irq resource\n");
ret = -ENOENT;
goto clean_ale_ret;
}
Maybe they should all be changed?
Yeah, I'd vote for it. I'm seeing no sense in overriding an actual error.
[...]
julia
MBR, Sergei
--
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 6/7] drivers: net: cpsw: fix error return code
> > diff --git a/drivers/net/ethernet/ti/cpsw.c
> > b/drivers/net/ethernet/ti/cpsw.c
> > index 3409e80..6a76992 100644
> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
> >
> > /* RX IRQ */
> > irq = platform_get_irq(pdev, 1);
> > - if (irq < 0)
> > + if (irq < 0) {
> > + ret = -ENOENT;
>
>Why not just propagate an error returned by that function?
OK, I did what was done a few lines before in the same function:
ndev->irq = platform_get_irq(pdev, 1);
if (ndev->irq < 0) {
dev_err(priv->dev, "error getting irq resource\n");
ret = -ENOENT;
goto clean_ale_ret;
}
Maybe they should all be changed?
julia
> > goto clean_ale_ret;
> > + }
> >
> > priv->irqs_table[0] = irq;
> > ret = devm_request_irq(>dev, irq, cpsw_rx_interrupt,
> > @@ -2461,8 +2463,10 @@ static int cpsw_probe(struct platform_device *pdev)
> >
> > /* TX IRQ */
> > irq = platform_get_irq(pdev, 2);
> > - if (irq < 0)
> > + if (irq < 0) {
> > + ret = -ENOENT;
>
>Likewise?
>
> [...]
>
> MBR, Sergei
>
>
--
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 6/7] drivers: net: cpsw: fix error return code
Hello.
On 12/26/2015 6:28 PM, Julia Lawall wrote:
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when !=
*if(...)
{
... when != ret = e2
when forall
return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/net/ethernet/ti/cpsw.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 3409e80..6a76992 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2448,8 +2448,10 @@ static int cpsw_probe(struct platform_device *pdev)
/* RX IRQ */
irq = platform_get_irq(pdev, 1);
- if (irq < 0)
+ if (irq < 0) {
+ ret = -ENOENT;
Why not just propagate an error returned by that function?
goto clean_ale_ret;
+ }
priv->irqs_table[0] = irq;
ret = devm_request_irq(>dev, irq, cpsw_rx_interrupt,
@@ -2461,8 +2463,10 @@ static int cpsw_probe(struct platform_device *pdev)
/* TX IRQ */
irq = platform_get_irq(pdev, 2);
- if (irq < 0)
+ if (irq < 0) {
+ ret = -ENOENT;
Likewise?
[...]
MBR, Sergei
--
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/
GPIO-driven RTS on TI hardware with 8250_omap driver
Hello. We are upgrading to the 4.1.x kernel for our smart metering appliance project, which is based on TI's Sitara hardware (AM335x SoC), and I decided to switch from omap-serial legacy driver to the newer 8250-based one. It marginally increases throughput efficiency, CPU cycle wise, among other goodies, but I'm looking to implement a rather important feature that is present in the legacy driver, but the newer one is lacking. Namely, our project makes use of RS232<->RS485 converters, which in turn need to consume RTS signals to switch between Rx and Tx modes at the RS485 side, due to the bus variant we use being half-duplex. However, the already manufactured hardware is already designed to make the use of certain pins to take the RTS signal from, which can only be configured as GPIO for that purpose (in other words, no "native" UART RTS) - and basically redesigning the h/w configuration now is definitely out of question. The omap-serial driver already provides FDT options for that, named "rts-gpio", "rs485-rts-active-high" etc. As far as I could ascertain, the 8250_omap driver (as well as the 8250 framework itself) at the moment lacks the means to make use of GPIO pins for that purpose. While trying to implement it myself, I noticed that the legacy driver has it made in a comparably straightforward approach, via dispatching the code to switch the pin in its .start_tx and .stop_tx handlers, and some timing adjustments. Unfortunately, the situation with 8250-based drivers is different - the aforementioned handlers are provided by the 8250_core module and are common for all drivers within the framework. At first, I thought that implementing such feature for the 8250 framework itself sounds like a good idea, but after reading this particular post: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271377.html I decided to comply with the point of view specified there. However, I'm not that familiar with the 8250 framework internals (or serial internals at all, for that matter), and my time is quite short, so I would appreciate much any useful directions on how to do it hardware-specific style, which functions/structs/handlers to use, etc. Of particular interest is the following part: > I don't care whether the drive does it via serial_out magic or a more > explicit hook but it doesn't belong here in core code. Any ideas/clarifications on what might be meant on that part? Regards, Ilyas G. -- 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] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
All new 32-bit architectures should have 64-bit off_t type, but existing architectures has 32-bit ones. To handle it, new config option is added to arch/Kconfig that defaults ARCH_32BIT_OFF_T to be disabled by default. All existing 32-bit architectures enable it explicitly here. New option affects force_o_largefile() behaviour. Namely, if off_t is 64-bits long, we have no reason to reject user to open big files. Signed-off-by: Yury Norov --- arch/Kconfig| 4 arch/arc/Kconfig| 1 + arch/arm/Kconfig| 1 + arch/blackfin/Kconfig | 1 + arch/cris/Kconfig | 1 + arch/frv/Kconfig| 1 + arch/h8300/Kconfig | 1 + arch/hexagon/Kconfig| 1 + arch/ia64/Kconfig | 1 + arch/m32r/Kconfig | 1 + arch/m68k/Kconfig | 1 + arch/metag/Kconfig | 1 + arch/microblaze/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/mn10300/Kconfig| 1 + arch/nios2/Kconfig | 1 + arch/openrisc/Kconfig | 1 + arch/parisc/Kconfig | 1 + arch/powerpc/Kconfig| 1 + arch/s390/Kconfig | 1 + arch/score/Kconfig | 1 + arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/tile/Kconfig | 1 + arch/unicore32/Kconfig | 1 + arch/x86/Kconfig| 1 + arch/x86/um/Kconfig | 1 + arch/xtensa/Kconfig | 1 + include/linux/fcntl.h | 3 ++- 29 files changed, 33 insertions(+), 1 deletion(-) diff --git a/arch/Kconfig b/arch/Kconfig index 4e949e5..1e5e6c8 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -233,6 +233,10 @@ config ARCH_THREAD_INFO_ALLOCATOR config ARCH_WANTS_DYNAMIC_TASK_STRUCT bool +config ARCH_32BIT_OFF_T + def_bool n + depends on !64BIT + config HAVE_REGS_AND_STACK_ACCESS_API bool help diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 6312f60..570dc39 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -9,6 +9,7 @@ config ARC def_bool y select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC + select ARCH_32BIT_OFF_T select BUILDTIME_EXTABLE_SORT select COMMON_CLK select CLONE_BACKWARDS diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 34e1569..dafdebe 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1,6 +1,7 @@ config ARM bool default y + select ARCH_32BIT_OFF_T select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index af76634..9b5fc06 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -12,6 +12,7 @@ config RWSEM_XCHGADD_ALGORITHM config BLACKFIN def_bool y + select ARCH_32BIT_OFF_T select HAVE_ARCH_KGDB select HAVE_ARCH_TRACEHOOK select HAVE_DYNAMIC_FTRACE diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig index e086f9e..5bc9203 100644 --- a/arch/cris/Kconfig +++ b/arch/cris/Kconfig @@ -50,6 +50,7 @@ config LOCKDEP_SUPPORT config CRIS bool default y + select ARCH_32BIT_OFF_T select HAVE_IDE select GENERIC_ATOMIC64 select HAVE_UID16 diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig index 34aa193..09b82fc 100644 --- a/arch/frv/Kconfig +++ b/arch/frv/Kconfig @@ -1,6 +1,7 @@ config FRV bool default y + select ARCH_32BIT_OFF_T select HAVE_IDE select HAVE_ARCH_TRACEHOOK select HAVE_PERF_EVENTS diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index dd3ac75..7761f4a 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -1,5 +1,6 @@ config H8300 def_bool y + select ARCH_32BIT_OFF_T select GENERIC_ATOMIC64 select HAVE_UID16 select VIRT_TO_BUS diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index 4dc89d1..29836fc 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -3,6 +3,7 @@ comment "Linux Kernel Configuration for Hexagon" config HEXAGON def_bool y + select ARCH_32BIT_OFF_T select HAVE_OPROFILE # Other pending projects/to-do items. # select HAVE_REGS_AND_STACK_ACCESS_API diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index eb0249e..370fcab 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -11,6 +11,7 @@ menu "Processor type and features" config IA64 bool + select ARCH_32BIT_OFF_T if !64BIT select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_MIGHT_HAVE_PC_SERIO select PCI if (!IA64_HP_SIM) diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig index 9e44bbd..c6865a9 100644 --- a/arch/m32r/Kconfig +++ b/arch/m32r/Kconfig @@ -1,6 +1,7 @@ config M32R bool default y + select ARCH_32BIT_OFF_T select HAVE_IDE select HAVE_OPROFILE select INIT_ALL_POSSIBLE diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 498b567..e9897e4 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@
