[PATCH] drm/vc4: fix build warning
We were getting build warning:
drivers/gpu/drm/vc4/vc4_validate.c: In function 'validate_gl_shader_rec':
drivers/gpu/drm/vc4/vc4_validate.c:864:4:
warning: format '%d' expects argument of type 'int', but argument 4 has type
'size_t' [-Wformat=]
DRM_ERROR("BO offset overflow (%d + %d > %d)\n",
vbo->base.size is size_t and for printing size_t we should be using %zu.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/vc4/vc4_validate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_validate.c
b/drivers/gpu/drm/vc4/vc4_validate.c
index 0fb5b99..e26d9f6 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
+++ b/drivers/gpu/drm/vc4/vc4_validate.c
@@ -861,7 +861,7 @@ validate_gl_shader_rec(struct drm_device *dev,
if (vbo->base.size < offset ||
vbo->base.size - offset < attr_size) {
- DRM_ERROR("BO offset overflow (%d + %d > %d)\n",
+ DRM_ERROR("BO offset overflow (%d + %d > %zu)\n",
offset, attr_size, vbo->base.size);
return -EINVAL;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: s2m,s5m: constify regulator_ops structures
On Wed, 23 Dec 2015, Mark Brown wrote: > On Sat, Dec 19, 2015 at 03:58:00PM +0100, Julia Lawall wrote: > > The regulator_ops structures are never modified, so declare them as const. > > > > Done with the help of Coccinelle. > > This doesn't apply against current code, please check and resend. It works fine for me on today's linux-next (80c75a0f1d). What goes wrong? 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 4/4] ASoC: Intel: add NULL test
On Wed, 23 Dec 2015, Mark Brown wrote: > On Sun, Dec 20, 2015 at 12:15:53PM +0100, Julia Lawall wrote: > > Add NULL test on call to devm_kzalloc. > > > > The semantic match that finds this problem is as follows: > > (http://coccinelle.lip6.fr/) > > If there was a patch 3 in this series I seem to be missing it. It's not for you (drivers/s390/char/con3215.c). Sorry for the confusion. 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 2/2] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous
On Wed, Dec 23, 2015 at 07:14:21AM +0100, Vlastimil Babka wrote: > On 22.12.2015 23:17, David Rientjes wrote: > > On Mon, 21 Dec 2015, Joonsoo Kim wrote: > > > >> Before vs After > >> Max: 1096 MB/s vs 1325 MB/s > >> Min: 635 MB/s 1015 MB/s > >> Avg: 899 MB/s 1194 MB/s > >> > >> Avg is improved by roughly 30% [2]. > >> > > > > Wow, ok! > > > > I'm wondering if it would be better to maintain this as a characteristic > > of each pageblock rather than each zone. Have you tried to introduce a > > couple new bits to pageblock_bits that would track (1) if a cached value > > makes sense and (2) if the pageblock is contiguous? On the first call to > > pageblock_pfn_to_page(), set the first bit, PB_cached, and set the second > > bit, PB_contiguous, iff it is contiguous. On subsequent calls, if > > PB_cached is true, then return PB_contiguous. On memory hot-add or > > remove (or init), clear PB_cached. > > I can imagine these bitmap operation to be as expensive as what > __pageblock_pfn_to_page() does (or close)? But if not, we could also just be a > bit smarter about PG_skip and check that before doing pfn_to_page. Although I don't think carefully, to get PB_xxx, we need to check pfn's zone and it requires pfn_valid() and pfn_to_page(). So, I guess that cost would be same or half compared to cost of __pageblock_pfn_to_page(). > > > What are the cases where pageblock_pfn_to_page() is used for a subset of > > the pageblock and the result would be problematic for compaction? I.e., > > do we actually care to use pageblocks that are not contiguous at all? > > The problematic pageblocks are those that have pages from more than one zone > in > them, so we just skip them. Supposedly that can only happen by switching once > between two zones somewhere in the middle of the pageblock, so it's sufficient > to check first and last pfn and compare their zones. So using > pageblock_pfn_to_page() on a subset from compaction would be wrong. Holes > (==no > pages) within pageblock is a different thing checked by pfn_valid_within() > (#defined out on archs where such holes cannot happen) when scanning the > block. > > That's why I'm not entirely happy with how the patch conflates both the > first/last pfn's zone checks and pfn_valid_within() checks. Yes, a fully > contiguous zone does *imply* that pageblock_pfn_to_page() doesn't have to > check > first/last pfn for a matching zone. But it's not *equality*. And any (now just > *potential*) user of pageblock_pfn_to_page() with pfn's different than > first/last pfn of a pageblock is likely wrong. Now, I understand your concern. What makes me mislead is that 3 of 4 callers to pageblock_pfn_to_page() in compaction.c could call it with non-pageblock boundary pfn. Maybe, they should be fixed first. Then, yes. I can separate first/last pfn's zone checks and pfn_valid_within() checks. If then, would you be entirely happy? :) 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/
[lkp] [blk] 26efb85d35: BUG kmalloc-512 (Not tainted): Redzone overwritten
FYI, we noticed the below changes on
git://internal_merge_and_test_tree devel-catchup-201512220028
commit 26efb85d35c71bc297e22773928062c97e41a8a2 ("blk-mq: dynamic h/w context
count")
++++
|| e56dda0be8 | 26efb85d35 |
++++
| boot_successes | 15 | 2 |
| boot_failures | 0 | 12 |
| BUG_kmalloc-#(Not_tainted):Poison_overwritten | 0 | 8 |
| INFO:#-#.First_byte#instead_of | 0 | 12 |
| INFO:Slab#objects=#used=#fp=0x(null)flags= | 0 | 12 |
| INFO:Object#@offset=#fp= | 0 | 12 |
| backtrace:init | 0 | 12 |
| backtrace:kernel_init_freeable | 0 | 12 |
| BUG_kmalloc-#(Not_tainted):Redzone_overwritten | 0 | 4 |
| BUG_kmalloc-#(Tainted:G_B):Redzone_overwritten | 0 | 4 |
| backtrace:vp_find_vqs | 0 | 4 |
| backtrace:init_vq | 0 | 4 |
| backtrace:ide_host_alloc | 0 | 4 |
| backtrace:ide_pci_init_two | 0 | 4 |
| backtrace:ide_pci_init_one | 0 | 4 |
| backtrace:piix_init_one| 0 | 4 |
| backtrace:ide_scan_pcibus | 0 | 4 |
++++
[ 14.781818] brd: module loaded
[ 14.818921] loop: module loaded
[ 18.033239]
=
[ 18.035280] BUG kmalloc-512 (Not tainted): Redzone overwritten
[ 18.036486]
-
[ 18.036486]
[ 18.039089] Disabling lock debugging due to kernel taint
[ 18.040287] INFO: 0x88007e0b55b0-0x88007e0b55b7. First byte 0x0
instead of 0xbb
[ 18.042289] INFO: Slab 0xea0001f82d00 objects=19 used=19 fp=0x
(null) flags=0x1004080
[ 18.044496] INFO: Object 0x88007e0b53b0 @offset=5040
fp=0x88007e0b56f8
[ 18.044496]
[ 18.046957] Bytes b4 88007e0b53a0: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[ 18.049075] Object 88007e0b53b0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.051240] Object 88007e0b53c0: 21 43 65 87 00 00 00 00 00 00 00 00 00
00 00 00 !Ce.
[ 18.053370] Object 88007e0b53d0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.055466] Object 88007e0b53e0: 00 00 00 00 00 00 00 00 21 43 65 87 00
00 00 00 !Ce.
[ 18.057562] Object 88007e0b53f0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.059653] Object 88007e0b5400: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.061817] Object 88007e0b5410: 21 43 65 87 00 00 00 00 00 00 00 00 00
00 00 00 !Ce.
[ 18.063933] Object 88007e0b5420: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.066024] Object 88007e0b5430: 00 00 00 00 00 00 00 00 21 43 65 87 00
00 00 00 !Ce.
[ 18.068141] Object 88007e0b5440: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.070246] Object 88007e0b5450: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.072341] Object 88007e0b5460: 21 43 65 87 00 00 00 00 00 00 00 00 00
00 00 00 !Ce.
[ 18.074462] Object 88007e0b5470: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.076561] Object 88007e0b5480: 00 00 00 00 00 00 00 00 21 43 65 87 00
00 00 00 !Ce.
[ 18.078663] Object 88007e0b5490: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.080804] Object 88007e0b54a0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.082917] Object 88007e0b54b0: 21 43 65 87 00 00 00 00 00 00 00 00 00
00 00 00 !Ce.
[ 18.085004] Object 88007e0b54c0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.087129] Object 88007e0b54d0: 00 00 00 00 00 00 00 00 21 43 65 87 00
00 00 00 !Ce.
[ 18.089217] Object 88007e0b54e0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.091373] Object 88007e0b54f0: 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
[ 18.093455] Object 88007e0b5500: 21 43 65 87 00 00 00 00 00 00 00 00 00
00 00 00 !Ce.
[ 18.095548] Object
[PATCH] clk: gpio: fix memory leak
If we fail to allocate parent_name then we are returning but we missed
freeing data which has already been allocated.
Signed-off-by: Sudip Mukherjee
---
drivers/clk/clk-gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 335322d..c1baa89 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -294,8 +294,10 @@ static void __init of_gpio_clk_setup(struct device_node
*node,
num_parents = of_clk_get_parent_count(node);
parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
- if (!parent_names)
+ if (!parent_names) {
+ kfree(data);
return;
+ }
for (i = 0; i < num_parents; i++)
parent_names[i] = of_clk_get_parent_name(node, i);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre/lustre/libcfs: Fix type mismatch reported by sparse
On Wed, Dec 23, 2015 at 3:34 AM, Dilger, Andreas
wrote:
> On 2015/12/22, 06:05, "Niranjan Dighe" wrote:
>
>>On Tue, Dec 22, 2015 at 5:14 AM, Greg Kroah-Hartman
>> wrote:
>>> On Wed, Dec 09, 2015 at 10:38:13PM +0530, Niranjan Dighe wrote:
The third argument to function kportal_memhog_alloc is expected to
be gfp_t whereas the actual argument was unsigned int. Fix this by
explicitly typecasting to gfp_t
Signed-off-by: Niranjan Dighe
---
drivers/staging/lustre/lustre/libcfs/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
b/drivers/staging/lustre/lustre/libcfs/module.c
index 96d9d46..9c79f6e 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -268,7 +268,7 @@ static int libcfs_ioctl_int(struct cfs_psdev_file
*pfile, unsigned long cmd,
/* XXX The ioc_flags is not GFP flags now, need
to be fixed */
err = kportal_memhog_alloc(pfile->private_data,
data->ioc_count,
-data->ioc_flags);
+ (__force gfp_t)data->ioc_flags);
>>>
>>> No, please fix the type to be correct properly, like the comment says
>>> needs to be done.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>>Hello Greg,
>>
>>I could see that the ioc_flags member of the struct libcfs_ioctl_data
>>is used as gfp_t only in the
>>case of the ioctl IOC_LIBCFS_MEMHOG. I can think of following ways to
>>correct it -
>>
>>1. Create a union that has 2 different types encapsulated, something like
>>this -
>>union {
>>__u32 ioc_flags;
>>gfp_t alloc_flags;
>>}flags;
>>Because, the ioc_flags seems to be used in different contexts at
>>different places throughout the
>>drivers/staging/lustre directory.
>>
>>2. Is it OK to hardcode the appropriate gfp_t flags for the
>>IOC_LIBCFS_MEMHOG, as the userspace
>>seems to be taking the decision about the page allocation
>>zone/strategy, is this what is intended?
>
> The memhog functionality is used to introduce memory pressure on a client
> or server during operation to test error handling as well as memory
> allocation deadlocks (e.g. GFP_KERNEL used where GFP_NOFS should be used).
> There are other ways to do this in the kernel today, so all of the memhog
> code could just be deleted I think.
>
> This looks like kportal_memhog_alloc(), kportal_memhog_free(),
> IOC_LIBCFS_MEMHOG, and struct libcfs_device_userstate could be removed.
>
>
> Cheers, Andreas
>
Thanks Andreas, I will send out a separate patch with the cleanup as
you suggested.
Regards,
Niranjan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous
On 22.12.2015 23:17, David Rientjes wrote: > On Mon, 21 Dec 2015, Joonsoo Kim wrote: > >> Before vs After >> Max: 1096 MB/s vs 1325 MB/s >> Min: 635 MB/s 1015 MB/s >> Avg: 899 MB/s 1194 MB/s >> >> Avg is improved by roughly 30% [2]. >> > > Wow, ok! > > I'm wondering if it would be better to maintain this as a characteristic > of each pageblock rather than each zone. Have you tried to introduce a > couple new bits to pageblock_bits that would track (1) if a cached value > makes sense and (2) if the pageblock is contiguous? On the first call to > pageblock_pfn_to_page(), set the first bit, PB_cached, and set the second > bit, PB_contiguous, iff it is contiguous. On subsequent calls, if > PB_cached is true, then return PB_contiguous. On memory hot-add or > remove (or init), clear PB_cached. I can imagine these bitmap operation to be as expensive as what __pageblock_pfn_to_page() does (or close)? But if not, we could also just be a bit smarter about PG_skip and check that before doing pfn_to_page. > What are the cases where pageblock_pfn_to_page() is used for a subset of > the pageblock and the result would be problematic for compaction? I.e., > do we actually care to use pageblocks that are not contiguous at all? The problematic pageblocks are those that have pages from more than one zone in them, so we just skip them. Supposedly that can only happen by switching once between two zones somewhere in the middle of the pageblock, so it's sufficient to check first and last pfn and compare their zones. So using pageblock_pfn_to_page() on a subset from compaction would be wrong. Holes (==no pages) within pageblock is a different thing checked by pfn_valid_within() (#defined out on archs where such holes cannot happen) when scanning the block. That's why I'm not entirely happy with how the patch conflates both the first/last pfn's zone checks and pfn_valid_within() checks. Yes, a fully contiguous zone does *imply* that pageblock_pfn_to_page() doesn't have to check first/last pfn for a matching zone. But it's not *equality*. And any (now just *potential*) user of pageblock_pfn_to_page() with pfn's different than first/last pfn of a pageblock is likely wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: Revert "dmaengine: mic_x100: add missing spin_unlock"
On Wed, Dec 23 2015 at 12:45:31 AM, Saurabh Sengar
wrote:
> On 23 December 2015 at 09:05, Ashutosh Dixit wrote:
>> This reverts commit e958e079e254 ("dmaengine: mic_x100: add missing
>> spin_unlock").
>>
>> The above patch is incorrect. There is nothing wrong with the original
>> code. The spin_lock is acquired in the "prep" functions and released
>> in "submit".
>
> Hi Ashutosh,
>
> If it is need to be released by submit function, we don't require the
> spin_unlock on success case as well.
> am I correct ?
No, you are wrong. In the prep functions, we are not using spin_unlock in
success cases but in failure ones.
>> Signed-off-by: Ashutosh Dixit
>> ---
>> drivers/dma/mic_x100_dma.c | 15 +--
>> 1 file changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c
>> index cddfa8d..068e920 100644
>> --- a/drivers/dma/mic_x100_dma.c
>> +++ b/drivers/dma/mic_x100_dma.c
>> @@ -317,7 +317,6 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch, dma_addr_t
>> dma_dest,
>> struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
>> struct device *dev = mic_dma_ch_to_device(mic_ch);
>> int result;
>> - struct dma_async_tx_descriptor *tx = NULL;
>>
>> if (!len && !flags)
>> return NULL;
>> @@ -325,13 +324,10 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch,
>> dma_addr_t dma_dest,
>> spin_lock(_ch->prep_lock);
>> result = mic_dma_do_dma(mic_ch, flags, dma_src, dma_dest, len);
>> if (result >= 0)
>> - tx = allocate_tx(mic_ch);
>> -
>> - if (!tx)
>> - dev_err(dev, "Error enqueueing dma, error=%d\n", result);
>> -
>> + return allocate_tx(mic_ch);
>> + dev_err(dev, "Error enqueueing dma, error=%d\n", result);
>> spin_unlock(_ch->prep_lock);
>
> This spin_unlock shouldn't be required as explained it is getting
> released by submit function
This is a failure case. Submit will not be called in this case so
spin_unlock needs to be called here.
>> - return tx;
>> + return NULL;
>> }
>>
>> static struct dma_async_tx_descriptor *
>> @@ -339,14 +335,13 @@ mic_dma_prep_interrupt_lock(struct dma_chan *ch,
>> unsigned long flags)
>> {
>> struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
>> int ret;
>> - struct dma_async_tx_descriptor *tx = NULL;
>>
>> spin_lock(_ch->prep_lock);
>> ret = mic_dma_do_dma(mic_ch, flags, 0, 0, 0);
>> if (!ret)
>> - tx = allocate_tx(mic_ch);
>> + return allocate_tx(mic_ch);
>> spin_unlock(_ch->prep_lock);
>
> and this too ?
Yes, this too.
>> - return tx;
>> + return NULL;
>> }
>>
>> /* Return the status of the transaction */
>> --
>> 2.0.0.rc3.2.g998f840
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply
Hi Jingoo,
On 12/23/2015 12:24 PM, Yakir Yang wrote:
Hi Jingoo,
On 12/22/2015 08:26 PM, Jingoo Han wrote:
On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
After test on rockchiop platform, i found sometims driver would failed
at reading EDID message. After debugging more, i found that it's okay
to read_a byte from i2c, but it would failed at AUX transcation if we
try to ready multi-bytes from i2c.
Driver just can't received the AUX CH reply command, even no AUX error
code. I may guess that the AUX wait time is not enough, so I try to
expand the AUX wait time, and i do see this could fix the EDID read
failed at rockchip platform.
And I thought that expand the wait time won't hurt Exynos platform too
much, cause Exynos didn't have this problem, then driver would received
the reply command very soon, so no more additional wait time would
bring
to Exynos platform.
Signed-off-by: Yakir Yang
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index c7e2959..dc376bd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct
analogix_dp_device *dp)
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
timeout_loop++;
-if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
No, I hate this coding.
analogix_dp_reg.c is the common code that can be shared by various SoCs.
Please, find another way.
Okay, I have double checked that i do have this problem in my side.
Hmmm.
I thought it's okay for you if I expand the "DP_TIMEOUT_LOOP_COUNT"
directly,
it won't hurt Exynos platform too much, cause Exynos didn't have this
problem,
then driver would received,the reply command very soon, so no more
additional
wait time would bring to Exynos platform.
Oh, sorry, little mistaken, I mean, is it okay for you to expand the
"DP_TIMEOUT_LOOP_COUNT" directly ?
- Yakir
And actually the datasheet haven't described the spec of aux reply
delay time.
Thanks,
- Yakir
Best regards,
Jingoo Han
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
--
1.9.1
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: Revert "dmaengine: mic_x100: add missing spin_unlock"
On 23 December 2015 at 09:05, Ashutosh Dixit wrote:
> This reverts commit e958e079e254 ("dmaengine: mic_x100: add missing
> spin_unlock").
>
> The above patch is incorrect. There is nothing wrong with the original
> code. The spin_lock is acquired in the "prep" functions and released
> in "submit".
Hi Ashutosh,
If it is need to be released by submit function, we don't require the
spin_unlock on success case as well.
am I correct ?
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/dma/mic_x100_dma.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c
> index cddfa8d..068e920 100644
> --- a/drivers/dma/mic_x100_dma.c
> +++ b/drivers/dma/mic_x100_dma.c
> @@ -317,7 +317,6 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch, dma_addr_t
> dma_dest,
> struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
> struct device *dev = mic_dma_ch_to_device(mic_ch);
> int result;
> - struct dma_async_tx_descriptor *tx = NULL;
>
> if (!len && !flags)
> return NULL;
> @@ -325,13 +324,10 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch,
> dma_addr_t dma_dest,
> spin_lock(_ch->prep_lock);
> result = mic_dma_do_dma(mic_ch, flags, dma_src, dma_dest, len);
> if (result >= 0)
> - tx = allocate_tx(mic_ch);
> -
> - if (!tx)
> - dev_err(dev, "Error enqueueing dma, error=%d\n", result);
> -
> + return allocate_tx(mic_ch);
> + dev_err(dev, "Error enqueueing dma, error=%d\n", result);
> spin_unlock(_ch->prep_lock);
This spin_unlock shouldn't be required as explained it is getting
released by submit function
> - return tx;
> + return NULL;
> }
>
> static struct dma_async_tx_descriptor *
> @@ -339,14 +335,13 @@ mic_dma_prep_interrupt_lock(struct dma_chan *ch,
> unsigned long flags)
> {
> struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
> int ret;
> - struct dma_async_tx_descriptor *tx = NULL;
>
> spin_lock(_ch->prep_lock);
> ret = mic_dma_do_dma(mic_ch, flags, 0, 0, 0);
> if (!ret)
> - tx = allocate_tx(mic_ch);
> + return allocate_tx(mic_ch);
> spin_unlock(_ch->prep_lock);
and this too ?
> - return tx;
> + return NULL;
> }
>
> /* Return the status of the transaction */
> --
> 2.0.0.rc3.2.g998f840
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dt: bindings: add bindings for ipq4019 wifi block
Add device tree binding documentation details for wifi block present
in Qualcomm IPQ4019 SoC into qcom,ath10k.txt.
Signed-off-by: Raja Mani
---
.../bindings/net/wireless/qcom,ath10k.txt | 87 --
1 file changed, 82 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index edefc26..ffd0742 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -1,17 +1,42 @@
* Qualcomm Atheros ath10k wireless devices
-For ath10k devices the calibration data can be provided through Device
-Tree. The node is a child node of the PCI controller.
-
Required properties:
--compatible : Should be "qcom,ath10k"
+- compatible: Should be one of the following:
+ * "qcom,ath10k"
+ * "qcom,ipq4019-wifi"
Optional properties:
+- reg: Address and length of the register set for the device.
+- core-id: Core number associated to the device.
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reseti.txt for details.
+- reset-names: Must include the list of following reset names,
+ "wifi_cpu_init"
+ "wifi_radio_srif"
+ "wifi_radio_warm"
+ "wifi_radio_cold"
+ "wifi_core_warm"
+ "wifi_core_cold"
+- clocks: List of clock specifiers, must contain an entry for each required
+ entry in clock-names.
+- clock-names: Should contain the clock names "wifi_wcss_cmd", "wifi_wcss_ref",
+ "wifi_wcss_rtc".
+- interrupts: List of interrupt lines. Must contain an entry
+ for each entry in the interrupt-names property.
+- interrupt-names: Must include the entries for MSI interrupt
+ names ("msi0" to "msi15") and legacy interrupt
+ name ("legacy"),
+- qca,msi_addr: MSI interrupt address.
+- qca,msi_base: Base value to add before writing MSI data into
+ MSI address register.
- qcom,ath10k-calibration-data : calibration data as an array, the
length can vary between hw versions
+- status: Either "disabled" or "ok".
+
+Example (to supply the calibration data alone):
-Example:
+In this example, the node is defined as child node of the PCI controller.
pci {
pcie@0 {
@@ -28,3 +53,55 @@ pci {
};
};
};
+
+Example (to supply ipq4019 SoC wifi block details):
+
+wifi0: wifi@a00 {
+ compatible = "qcom,ipq4019-wifi";
+ reg = <0xa00 0x20>;
+ core-id = <0x0>;
+ resets = < WIFI0_CPU_INIT_RESET>,
+< WIFI0_RADIO_SRIF_RESET>,
+< WIFI0_RADIO_WARM_RESET>,
+< WIFI0_RADIO_COLD_RESET>,
+< WIFI0_CORE_WARM_RESET>,
+< WIFI0_CORE_COLD_RESET>;
+ reset-names = "wifi_cpu_init",
+ "wifi_radio_srif",
+ "wifi_radio_warm",
+ "wifi_radio_cold",
+ "wifi_core_warm",
+ "wifi_core_cold";
+ clocks = < GCC_WCSS2G_CLK>,
+< GCC_WCSS2G_REF_CLK>,
+< GCC_WCSS2G_RTC_CLK>;
+ clock-names = "wifi_wcss_cmd",
+ "wifi_wcss_ref",
+ "wifi_wcss_rtc";
+ interrupts = <0 0x20 0x1>,
+<0 0x21 0x1>,
+<0 0x22 0x1>,
+<0 0x23 0x1>,
+<0 0x24 0x1>,
+<0 0x25 0x1>,
+<0 0x26 0x1>,
+<0 0x27 0x1>,
+<0 0x28 0x1>,
+<0 0x29 0x1>,
+<0 0x2a 0x1>,
+<0 0x2b 0x1>,
+<0 0x2c 0x1>,
+<0 0x2d 0x1>,
+<0 0x2e 0x1>,
+<0 0x2f 0x1>,
+<0 0xa8 0x0>;
+ interrupt-names = "msi0", "msi1", "msi2", "msi3",
+ "msi4", "msi5", "msi6", "msi7",
+ "msi8", "msi9", "msi10", "msi11",
+ "msi12", "msi13", "msi14", "msi15",
+ "legacy";
+ status = "ok";
+ qca,msi_addr = <0x0b006040>;
+ qca,msi_base = <0x40>;
+ qcom,ath10k-calibration-data = [ 01 02 03 ... ];
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/7][v4] Add OTG support for FSL socs
Hi > -Original Message- > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of Felipe Balbi > Sent: Wednesday, December 23, 2015 2:21 AM > To: Ramneek Mehresh ; linux- > ker...@vger.kernel.org > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > u...@vger.kernel.org > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs > > > Hi, > > Ramneek Mehresh writes: > >> -Original Message- > >> From: Felipe Balbi [mailto:ba...@ti.com] > >> Sent: Saturday, October 10, 2015 3:04 AM > >> To: Mehresh Ramneek-B31383 ; linux- > >> ker...@vger.kernel.org > >> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux- > >> u...@vger.kernel.org; Mehresh Ramneek-B31383 > >> > >> Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs > >> > >> Felipe Balbi writes: > >> > >> > Hi, > >> > > >> > Ramneek Mehresh writes: > >> >> Add support for otg for all freescale socs having internal usb phy. > >> >> > >> >> Ramneek Mehresh (7): > >> >> usb:fsl:otg: Make fsl otg driver as tristate > >> >> usb:fsl:otg: Add controller version based ULPI and UTMI phy > >> >> usb:fsl:otg: Add support to add/remove usb host driver > >> >> usb:fsl:otg: Signal host drv when host is otg > >> >> usb:fsl:otg: Modify otg_event to start host drv > >> >> usb:fsl:otg: Combine host/gadget start/resume for ID change > >> >> usb:fsl:otg: Add host-gadget drv sync delay > >> > > >> > Unless Alan's okay with the host side changes, I can't accept any > >> > of these. However, I must say some of the flags you add here > >> > already exist in some way, shape or form. For example, look at > is_b_host flag. > >> > > > > Could you please be more specific...which flag you think that I should > >remove/I'm re-defining. The flags I'm defining are: > > > > have_hcd : defined in fsl specific structure for fsl specific use-case > > > > had_hcd: defined in fsl specific structure for fsl specific use-case > > > > is_otg : defined in include/linux/usb.h > > > > Are you suggesting using otg_port or is_b_host instead of is_otg? > > > > As I understand, is_b_host is specifically to check if an otg B device > > is in host mode...correct? I just need a flag to check if a > > controller is capable of otg operations? That's why defined "is_otg" > > flag. Please suggest. > > no, I don't know why I made that comment. You could use otg_port, but that > wouldn't look very clean. Can you resend with Alan's ack, then I'll move > this series into testing/next. > > -- > balbi Can you directly put the change_hcd_work in its phy driver(phy-fsl-usb.c)? Then add/remove hcd will not through ehci_fsl_drv_suspend/resume, With this, you can make it work without a new flag "is_otg". Li Jun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
KVM: memory ballooning bug?
During my compaction-related stuff, I encountered some problems with ballooning. Firstly, with repeated inflating and deflating cycle, guest memory(ie, cat /proc/meminfo | grep MemTotal) decreased and couldn't recover. When I review source code, balloon_lock should cover release_pages_balloon. Otherwise, struct virtio_balloon fields could be overwritten by race of fill_balloon(e,g, vb->*pfns could be critical). Below patch fixed the problem. diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 7efc32945810..7d3e5d0e9aa4 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -209,8 +209,8 @@ static unsigned leak_balloon(struct virtio_balloon *vb, size_t num) */ if (vb->num_pfns != 0) tell_host(vb, vb->deflate_vq); - mutex_unlock(>balloon_lock); release_pages_balloon(vb); + mutex_unlock(>balloon_lock); return num_freed_pages; } Secondly, in balloon_page_dequeue, pages_lock should cover list_for_each_entry_safe loop. Otherwise, the cursor page could be isolated by compaction and then list_del by isolation could poison the page->lru so the loop could access wrong address like this. general protection fault: [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1+ #1906 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 task: 8800a7ff ti: 8800a7fec000 task.ti: 8800a7fec000 RIP: 0010:[] [] balloon_page_dequeue+0x54/0x130 RSP: 0018:8800a7fefdc0 EFLAGS: 00010246 RAX: 88013fff9a70 RBX: ea56fe00 RCX: 2b7d RDX: 88013fff9a70 RSI: ea56fe00 RDI: 88013fff9a68 RBP: 8800a7fefde8 R08: ea56fda0 R09: R10: 8800a7fefd90 R11: 0001 R12: dead00e0 R13: ea56fe20 R14: 880138809070 R15: 880138809060 FS: () GS:88013fc4() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 7f229c10e000 CR3: b8b53000 CR4: 06a0 Stack: 0100 880138809088 880138809000 880138809060 0046 8800a7fefe28 812c86d3 880138809020 880138809000 fff91900 0100 880138809060 Call Trace: [] leak_balloon+0x93/0x1a0 [] balloon+0x217/0x2a0 [] ? __schedule+0x31e/0x8b0 [] ? abort_exclusive_wait+0xb0/0xb0 [] ? update_balloon_stats+0xf0/0xf0 [] kthread+0xc9/0xe0 [] ? kthread_park+0x60/0x60 [] ret_from_fork+0x3f/0x70 [] ? kthread_park+0x60/0x60 Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89 RIP [] balloon_page_dequeue+0x54/0x130 RSP ---[ end trace 43cf28060d708d5f ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled We could fix it by protecting the entire loop by pages_lock but problem is irq latency during walking the list. But I doubt how often such worst scenario happens because in normal situation, the loop would exit easily via succeeding trylock_page. Any comments? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] crypto: KEYS: convert public key to the akcipher api
This patch converts the module verification code to the new akcipher API.
Signed-off-by: Tadeusz Struk
---
crypto/asymmetric_keys/Kconfig|2
crypto/asymmetric_keys/Makefile |7 -
crypto/asymmetric_keys/pkcs7_parser.c | 12 +-
crypto/asymmetric_keys/pkcs7_trust.c |2
crypto/asymmetric_keys/pkcs7_verify.c |2
crypto/asymmetric_keys/public_key.c | 64 +++--
crypto/asymmetric_keys/public_key.h | 36 -
crypto/asymmetric_keys/rsa.c | 213 +++--
crypto/asymmetric_keys/x509_cert_parser.c | 37 +
crypto/asymmetric_keys/x509_public_key.c | 17 +-
crypto/asymmetric_keys/x509_rsakey.asn1 |4 -
include/crypto/public_key.h | 48 +--
12 files changed, 135 insertions(+), 309 deletions(-)
delete mode 100644 crypto/asymmetric_keys/public_key.h
delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 4870f28..905d745 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -22,7 +22,7 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
config PUBLIC_KEY_ALGO_RSA
tristate "RSA public-key algorithm"
- select MPILIB
+ select CRYPTO_RSA
help
This option enables support for the RSA algorithm (PKCS#1, RFC3447).
diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
index cd1406f..b78a194 100644
--- a/crypto/asymmetric_keys/Makefile
+++ b/crypto/asymmetric_keys/Makefile
@@ -16,21 +16,18 @@ obj-$(CONFIG_X509_CERTIFICATE_PARSER) += x509_key_parser.o
x509_key_parser-y := \
x509-asn1.o \
x509_akid-asn1.o \
- x509_rsakey-asn1.o \
x509_cert_parser.o \
x509_public_key.o
$(obj)/x509_cert_parser.o: \
$(obj)/x509-asn1.h \
- $(obj)/x509_akid-asn1.h \
- $(obj)/x509_rsakey-asn1.h
+ $(obj)/x509_akid-asn1.h
+
$(obj)/x509-asn1.o: $(obj)/x509-asn1.c $(obj)/x509-asn1.h
$(obj)/x509_akid-asn1.o: $(obj)/x509_akid-asn1.c $(obj)/x509_akid-asn1.h
-$(obj)/x509_rsakey-asn1.o: $(obj)/x509_rsakey-asn1.c $(obj)/x509_rsakey-asn1.h
clean-files+= x509-asn1.c x509-asn1.h
clean-files+= x509_akid-asn1.c x509_akid-asn1.h
-clean-files+= x509_rsakey-asn1.c x509_rsakey-asn1.h
#
# PKCS#7 message handling
diff --git a/crypto/asymmetric_keys/pkcs7_parser.c
b/crypto/asymmetric_keys/pkcs7_parser.c
index 758acab..12912c1 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
#include "pkcs7-asn1.h"
@@ -44,7 +44,7 @@ struct pkcs7_parse_context {
static void pkcs7_free_signed_info(struct pkcs7_signed_info *sinfo)
{
if (sinfo) {
- mpi_free(sinfo->sig.mpi[0]);
+ kfree(sinfo->sig.s);
kfree(sinfo->sig.digest);
kfree(sinfo->signing_cert_id);
kfree(sinfo);
@@ -616,16 +616,14 @@ int pkcs7_sig_note_signature(void *context, size_t hdrlen,
const void *value, size_t vlen)
{
struct pkcs7_parse_context *ctx = context;
- MPI mpi;
BUG_ON(ctx->sinfo->sig.pkey_algo != PKEY_ALGO_RSA);
- mpi = mpi_read_raw_data(value, vlen);
- if (!mpi)
+ ctx->sinfo->sig.s = kmemdup(value, vlen, GFP_KERNEL);
+ if (!ctx->sinfo->sig.s)
return -ENOMEM;
- ctx->sinfo->sig.mpi[0] = mpi;
- ctx->sinfo->sig.nr_mpi = 1;
+ ctx->sinfo->sig.s_size = vlen;
return 0;
}
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index 90d6d47..3bbdcc7 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
/**
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c
b/crypto/asymmetric_keys/pkcs7_verify.c
index 325575c..f5db137 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -16,7 +16,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
/*
diff --git a/crypto/asymmetric_keys/public_key.c
b/crypto/asymmetric_keys/public_key.c
index 6db4c01..b383629 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -18,24 +18,16 @@
#include
#include
#include
-#include "public_key.h"
+#include
MODULE_LICENSE("GPL");
const char *const pkey_algo_name[PKEY_ALGO__LAST] = {
- [PKEY_ALGO_DSA] = "DSA",
- [PKEY_ALGO_RSA] = "RSA",
+ [PKEY_ALGO_DSA] = "dsa",
+ [PKEY_ALGO_RSA] = "rsa",
};
EXPORT_SYMBOL_GPL(pkey_algo_name);
-const struct public_key_algorithm *pkey_algo[PKEY_ALGO__LAST] = {
-#if
[PATCH v3 2/2] integrity: convert digsig to akcipher api
Convert asymmetric_verify to akcipher api.
Signed-off-by: Tadeusz Struk
---
security/integrity/Kconfig |1 +
security/integrity/digsig_asymmetric.c | 10 +++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 73c457b..f0b2463 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -36,6 +36,7 @@ config INTEGRITY_ASYMMETRIC_KEYS
select ASYMMETRIC_KEY_TYPE
select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
select PUBLIC_KEY_ALGO_RSA
+select CRYPTO_RSA
select X509_CERTIFICATE_PARSER
help
This option enables digital signature verification using
diff --git a/security/integrity/digsig_asymmetric.c
b/security/integrity/digsig_asymmetric.c
index 4fec181..5629372 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -92,13 +92,9 @@ int asymmetric_verify(struct key *keyring, const char *sig,
pks.pkey_hash_algo = hdr->hash_algo;
pks.digest = (u8 *)data;
pks.digest_size = datalen;
- pks.nr_mpi = 1;
- pks.rsa.s = mpi_read_raw_data(hdr->sig, siglen);
-
- if (pks.rsa.s)
- ret = verify_signature(key, );
-
- mpi_free(pks.rsa.s);
+ pks.s = hdr->sig;
+ pks.s_size = siglen;
+ ret = verify_signature(key, );
key_put(key);
pr_debug("%s() = %d\n", __func__, ret);
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] crypto: KEYS: convert public key to akcipher api
This patch set converts the module verification and digital signature code to the new akcipher API. RSA implementation has been removed from crypto/asymmetric_keys and the new API is used for cryptographic primitives. There is no need for MPI above the akcipher API anymore. Modules can be verified with software as well as HW RSA implementations. Patches generated against cryptodev-2.6 Changes in v3: - Don't include keys/asymmetric-type.h in crypto/public_key.h Changes in v2: - Fix the whey public_key_signature is setup. The pointer s needs to point to the signature instread of the signature_v2_hdr. - Select CRYPTO_RSA when INTEGRITY_ASYMMETRIC_KEYS is selected. --- Tadeusz Struk (2): crypto: KEYS: convert public key to the akcipher api integrity: convert digsig to akcipher api crypto/asymmetric_keys/Kconfig|2 crypto/asymmetric_keys/Makefile |7 - crypto/asymmetric_keys/pkcs7_parser.c | 12 +- crypto/asymmetric_keys/pkcs7_trust.c |2 crypto/asymmetric_keys/pkcs7_verify.c |2 crypto/asymmetric_keys/public_key.c | 64 +++-- crypto/asymmetric_keys/public_key.h | 36 - crypto/asymmetric_keys/rsa.c | 213 +++-- crypto/asymmetric_keys/x509_cert_parser.c | 37 + crypto/asymmetric_keys/x509_public_key.c | 17 +- crypto/asymmetric_keys/x509_rsakey.asn1 |4 - include/crypto/public_key.h | 48 ++- security/integrity/Kconfig|1 security/integrity/digsig_asymmetric.c| 10 - 14 files changed, 139 insertions(+), 316 deletions(-) delete mode 100644 crypto/asymmetric_keys/public_key.h delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1 -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] crypto: KEYS: convert public key to the akcipher api
On 12/22/2015 06:33 PM, Herbert Xu wrote: >> What about the first two. This one is completely unrelated. >> > It only supposed to fix some random configuration issue >> > reported by a build robot, which isn't really important now. >> > The other two convert the module verifier to the new API. > No this compile breakage was introduced by your first two patches > because you changed crypto/public_key.h which is used by entities > outside of your patch. > > So fix your first two patches by not breaking existing users > of it. Ok I can see the problem now. I just don't should not include the asymmetric-type.h in the public_key.h and it fixes it. Will send v3 soon. Thanks, -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drm fixes
Hi Linus, Not much happening, should have dequeued this lot earlier, One amdgpu, one nouveau and one exynos fix. Dave. The following changes since commit 76b8ebdc4c7a8299e6365428a36cc0fb1c2a4103: Merge tag 'media/v4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2015-12-18 15:41:35 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 1957d62c29be413d77da2e69737f4251e5449fbd: Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2015-12-20 08:51:34 +1000) Andrzej Hajda (1): drm/exynos: atomic check only enabled crtc states Christian König (1): drm/amdgpu: fix user fence handling Dave Airlie (3): Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'linux-4.4' of git://github.com/skeggsb/linux into drm-fixes Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Martin Peres (1): drm/nouveau/bios/fan: hardcode the fan mode to linear drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 63 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 ++ drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c | 1 + 4 files changed, 48 insertions(+), 22 deletions(-)
[PATCH 3/8] cgroup: introduce cgroup namespaces
From: Aditya Kali
Introduce the ability to create new cgroup namespace. The newly created
cgroup namespace remembers the cgroup of the process at the point
of creation of the cgroup namespace (referred as cgroupns-root).
The main purpose of cgroup namespace is to virtualize the contents
of /proc/self/cgroup file. Processes inside a cgroup namespace
are only able to see paths relative to their namespace root
(unless they are moved outside of their cgroupns-root, at which point
they will see a relative path from their cgroupns-root).
For a correctly setup container this enables container-tools
(like libcontainer, lxc, lmctfy, etc.) to create completely virtualized
containers without leaking system level cgroup hierarchy to the task.
This patch only implements the 'unshare' part of the cgroupns.
Signed-off-by: Aditya Kali
Signed-off-by: Serge Hallyn
---
Changelog: 2015-11-24
- move cgroup_namespace.c into cgroup.c (and .h)
- reformatting
- make get_cgroup_ns return void
- rename ns->root_cgrps to root_cset.
Changelog: 2015-12-08
- Move init_cgroup_ns to other variable declarations
- Remove accidental conversion of put-css_set to inline
- Drop BUG_ON(NULL)
- Remove unneeded pre declaration of struct cgroupns_operations.
- cgroup.h: collect common ns declerations
Changelog: 2015-12-09
- cgroup.h: move ns declarations to bottom
- cgroup.c: undo all accidental conversions to inline
Changelog: 2015-12-22
- update for new kernfs_path_from_node() return value. Since
cgroup_path was already gpl-exported, I abstained from updating
its return value.
---
fs/proc/namespaces.c|3 +
include/linux/cgroup.h | 54 --
include/linux/nsproxy.h |2 +
include/linux/proc_ns.h |4 ++
kernel/cgroup.c | 144 +++
kernel/fork.c |2 +-
kernel/nsproxy.c| 21 ++-
7 files changed, 221 insertions(+), 9 deletions(-)
diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
index f6e8354..bd61075 100644
--- a/fs/proc/namespaces.c
+++ b/fs/proc/namespaces.c
@@ -28,6 +28,9 @@ static const struct proc_ns_operations *ns_entries[] = {
_operations,
#endif
_operations,
+#ifdef CONFIG_CGROUPS
+ _operations,
+#endif
};
static const char *proc_ns_follow_link(struct dentry *dentry, void **cookie)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 9d70b48..6d0992f 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -17,6 +17,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -532,12 +537,6 @@ static inline int cgroup_name(struct cgroup *cgrp, char
*buf, size_t buflen)
return kernfs_name(cgrp->kn, buf, buflen);
}
-static inline char * __must_check cgroup_path(struct cgroup *cgrp, char *buf,
- size_t buflen)
-{
- return kernfs_path(cgrp->kn, buf, buflen);
-}
-
static inline void pr_cont_cgroup_name(struct cgroup *cgrp)
{
pr_cont_kernfs_name(cgrp->kn);
@@ -570,4 +569,47 @@ static inline int cgroup_init(void) { return 0; }
#endif /* !CONFIG_CGROUPS */
+struct cgroup_namespace {
+ atomic_tcount;
+ struct ns_commonns;
+ struct user_namespace *user_ns;
+ struct css_set *root_cset;
+};
+
+extern struct cgroup_namespace init_cgroup_ns;
+
+#ifdef CONFIG_CGROUPS
+
+void free_cgroup_ns(struct cgroup_namespace *ns);
+
+struct cgroup_namespace *
+copy_cgroup_ns(unsigned long flags, struct user_namespace *user_ns,
+ struct cgroup_namespace *old_ns);
+
+char *cgroup_path(struct cgroup *cgrp, char *buf, size_t buflen);
+
+#else /* !CONFIG_CGROUPS */
+
+static inline void free_cgroup_ns(struct cgroup_namespace *ns) { }
+static inline struct cgroup_namespace *
+copy_cgroup_ns(unsigned long flags, struct user_namespace *user_ns,
+ struct cgroup_namespace *old_ns)
+{
+ return old_ns;
+}
+
+#endif /* !CONFIG_CGROUPS */
+
+static inline void get_cgroup_ns(struct cgroup_namespace *ns)
+{
+ if (ns)
+ atomic_inc(>count);
+}
+
+static inline void put_cgroup_ns(struct cgroup_namespace *ns)
+{
+ if (ns && atomic_dec_and_test(>count))
+ free_cgroup_ns(ns);
+}
+
#endif /* _LINUX_CGROUP_H */
diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h
index 35fa08f..ac0d65b 100644
--- a/include/linux/nsproxy.h
+++ b/include/linux/nsproxy.h
@@ -8,6 +8,7 @@ struct mnt_namespace;
struct uts_namespace;
struct ipc_namespace;
struct pid_namespace;
+struct cgroup_namespace;
struct fs_struct;
/*
@@ -33,6 +34,7 @@ struct nsproxy {
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns_for_children;
struct net *net_ns;
+ struct cgroup_namespace *cgroup_ns;
};
extern struct nsproxy
[PATCH 1/8] kernfs: Add API to generate relative kernfs path
From: Aditya Kali
The new function kernfs_path_from_node() generates and returns kernfs
path of a given kernfs_node relative to a given parent kernfs_node.
Signed-off-by: Aditya Kali
Signed-off-by: Serge E. Hallyn
---
Changelog 20151125:
- Fully-wing multilinecomments
- Rework kernfs_path_from_node_locked() logic
- Replace BUG_ONs with returning NULL
- Use a const char* for /.. and precalculate its size
Changelog 20151130:
- Update kernfs_path_from_node_locked comment
Changelog 20151208:
- kernfs_node_distance:
* Remove BUG_ON(NULL)s
* Rename kernfs_node_distance to kernfs_depth
- kernfs_common-ancestor:
* Remove useless checks for depth == 0
* Add check to ensure nodes are from same root
- kernfs_path_from_node_locked:
* Remove needless __must_check
* Put p;len on its own decl line.
* Fix wrong WARN_ONCE usage
Changelog 20151209:
- kernfs_path_from_node: change arguments to 'to' and 'from', and
change their order.
Changelog 20151222:
- kernfs_path_from_node{,_locked}: return the string length.
kernfs_path is gpl-exported, so changing their return value seemed
ill-advised, but if noone minds I can update it too.
---
fs/kernfs/dir.c| 205
include/linux/kernfs.h |9 ++-
2 files changed, 179 insertions(+), 35 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 742bf4a..e82b9a1 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -44,28 +44,123 @@ static int kernfs_name_locked(struct kernfs_node *kn, char
*buf, size_t buflen)
return strlcpy(buf, kn->parent ? kn->name : "/", buflen);
}
-static char * __must_check kernfs_path_locked(struct kernfs_node *kn, char
*buf,
- size_t buflen)
+/* kernfs_node_depth - compute depth from @from to @to */
+static size_t kernfs_depth(struct kernfs_node *from, struct kernfs_node *to)
{
- char *p = buf + buflen;
- int len;
+ size_t depth = 0;
- *--p = '\0';
+ while (to->parent && to != from) {
+ depth++;
+ to = to->parent;
+ }
+ return depth;
+}
- do {
- len = strlen(kn->name);
- if (p - buf < len + 1) {
- buf[0] = '\0';
- p = NULL;
- break;
- }
- p -= len;
- memcpy(p, kn->name, len);
- *--p = '/';
- kn = kn->parent;
- } while (kn && kn->parent);
+static struct kernfs_node *kernfs_common_ancestor(struct kernfs_node *a,
+ struct kernfs_node *b)
+{
+ size_t da, db;
+ struct kernfs_root *ra = kernfs_root(a), *rb = kernfs_root(b);
+
+ if (ra != rb)
+ return NULL;
+
+ da = kernfs_depth(ra->kn, a);
+ db = kernfs_depth(rb->kn, b);
+
+ while (da > db) {
+ a = a->parent;
+ da--;
+ }
+ while (db > da) {
+ b = b->parent;
+ db--;
+ }
+
+ /* worst case b and a will be the same at root */
+ while (b != a) {
+ b = b->parent;
+ a = a->parent;
+ }
+
+ return a;
+}
+
+/**
+ * kernfs_path_from_node_locked - find a pseudo-absolute path to @kn_to,
+ * where kn_from is treated as root of the path.
+ * @kn_from: kernfs node which should be treated as root for the path
+ * @kn_to: kernfs node to which path is needed
+ * @buf: buffer to copy the path into
+ * @buflen: size of @buf
+ *
+ * We need to handle couple of scenarios here:
+ * [1] when @kn_from is an ancestor of @kn_to at some level
+ * kn_from: /n1/n2/n3
+ * kn_to: /n1/n2/n3/n4/n5
+ * result: /n4/n5
+ *
+ * [2] when @kn_from is on a different hierarchy and we need to find common
+ * ancestor between @kn_from and @kn_to.
+ * kn_from: /n1/n2/n3/n4
+ * kn_to: /n1/n2/n5
+ * result: /../../n5
+ * OR
+ * kn_from: /n1/n2/n3/n4/n5 [depth=5]
+ * kn_to: /n1/n2/n3 [depth=3]
+ * result: /../..
+ *
+ * return value: length of the string. If greater than buflen,
+ * then contents of buf are undefined. On error, -1 is returned.
+ */
+static int
+kernfs_path_from_node_locked(struct kernfs_node *kn_to,
+struct kernfs_node *kn_from, char *buf,
+size_t buflen)
+{
+ struct kernfs_node *kn, *common;
+ const char parent_str[] = "/..";
+ size_t depth_from, depth_to, len = 0, nlen = 0;
+ char *p;
+ int i;
+
+ if (!kn_from)
+ kn_from = kernfs_root(kn_to)->kn;
+
+ if (kn_from == kn_to)
+ return strlcpy(buf, "/", buflen);
+
+ common = kernfs_common_ancestor(kn_from, kn_to);
+ if (WARN_ON(!common))
+ return -1;
+
+ depth_to
[PATCH 6/8] cgroup: mount cgroupns-root when inside non-init cgroupns
From: Serge Hallyn
This patch enables cgroup mounting inside userns when a process
as appropriate privileges. The cgroup filesystem mounted is
rooted at the cgroupns-root. Thus, in a container-setup, only
the hierarchy under the cgroupns-root is exposed inside the container.
This allows container management tools to run inside the containers
without depending on any global state.
Signed-off-by: Serge Hallyn
---
Changelog:
20151116 - Don't allow user namespaces to bind new subsystems
20151118 - postpone the FS_USERNS_MOUNT flag until the
last patch, until we can convince ourselves it
is safe.
20151207 - Switch to walking up the kernfs path from kn root.
- Group initialized variables
- Explain the capable(CAP_SYS_ADMIN) check
- Style fixes
---
kernel/cgroup.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e85fbf9..99c4443 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1983,6 +1983,7 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
{
bool is_v2 = fs_type == _fs_type;
struct super_block *pinned_sb = NULL;
+ struct cgroup_namespace *ns = current->nsproxy->cgroup_ns;
struct cgroup_subsys *ss;
struct cgroup_root *root;
struct cgroup_sb_opts opts;
@@ -1991,6 +1992,14 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
int i;
bool new_sb;
+ get_cgroup_ns(ns);
+
+ /* Check if the caller has permission to mount. */
+ if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN)) {
+ put_cgroup_ns(ns);
+ return ERR_PTR(-EPERM);
+ }
+
/*
* The first time anyone tries to mount a cgroup, enable the list
* linking each css_set to its tasks and fix up all existing tasks.
@@ -2106,6 +2115,16 @@ static struct dentry *cgroup_mount(struct
file_system_type *fs_type,
goto out_unlock;
}
+ /*
+* We know this subsystem has not yet been bound. Users in a non-init
+* user namespace may only mount hierarchies with no bound subsystems,
+* i.e. 'none,name=user1'
+*/
+ if (!opts.none && !capable(CAP_SYS_ADMIN)) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
root = kzalloc(sizeof(*root), GFP_KERNEL);
if (!root) {
ret = -ENOMEM;
@@ -2124,12 +2143,30 @@ out_free:
kfree(opts.release_agent);
kfree(opts.name);
- if (ret)
+ if (ret) {
+ put_cgroup_ns(ns);
return ERR_PTR(ret);
+ }
out_mount:
dentry = kernfs_mount(fs_type, flags, root->kf_root,
is_v2 ? CGROUP2_SUPER_MAGIC : CGROUP_SUPER_MAGIC,
_sb);
+
+ /*
+* In non-init cgroup namespace, instead of root cgroup's
+* dentry, we return the dentry corresponding to the
+* cgroupns->root_cgrp.
+*/
+ if (!IS_ERR(dentry) && ns != _cgroup_ns) {
+ struct dentry *nsdentry;
+ struct cgroup *cgrp;
+
+ cgrp = cset_cgroup_from_root(ns->root_cset, root);
+ nsdentry = kernfs_node_dentry(cgrp->kn, dentry->d_sb);
+ dput(dentry);
+ dentry = nsdentry;
+ }
+
if (IS_ERR(dentry) || !new_sb)
cgroup_put(>cgrp);
@@ -2142,6 +2179,7 @@ out_mount:
deactivate_super(pinned_sb);
}
+ put_cgroup_ns(ns);
return dentry;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] Add FS_USERNS_FLAG to cgroup fs
From: Serge Hallyn
allowing root in a non-init user namespace to mount it. This should
now be safe, because
1. non-init-root cannot mount a previously unbound subsystem
2. the task doing the mount must be privileged with respect to the
user namespace owning the cgroup namespace
3. the mounted subsystem will have its current cgroup as the root dentry.
the permissions will be unchanged, so tasks will receive no new
privilege over the cgroups which they did not have on the original
mounts.
Signed-off-by: Serge Hallyn
---
kernel/cgroup.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 99c4443..587247e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2208,12 +2208,14 @@ static struct file_system_type cgroup_fs_type = {
.name = "cgroup",
.mount = cgroup_mount,
.kill_sb = cgroup_kill_sb,
+ .fs_flags = FS_USERNS_MOUNT,
};
static struct file_system_type cgroup2_fs_type = {
.name = "cgroup2",
.mount = cgroup_mount,
.kill_sb = cgroup_kill_sb,
+ .fs_flags = FS_USERNS_MOUNT,
};
static int cgroup_path_ns(struct cgroup *cgrp, char *buf, size_t buflen,
--
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: comedi: fix block comments coding style issue in comedi.h
On Wed, Dec 23, 2015 at 10:51:11AM +0800, maoma king wrote:
> Dear Greg
> I have sent my first patch (https://lkml.org/lkml/2015/11/18/239) to
> linux-next tree.But I never received anything about it.So I sent it
> again. You say "Doesn't apply to my tree :(".but it can be apply to
> least linux-next branch .
> I make n new patch and send it.I receive
> review(https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1048115.html)
> .
> I want to know what's wrong with me?
Nothing is wrong with me. Just work with staging-testing branch of
staging tree and everything should be fine. Ofcourse, if some one else
sends another patch before you touching the same code that you have
worked on then your patch may not apply. But that is part of the game.
> how do I know that my patch is accepted?
When Greg applies any patch to his tree, one confirmation mail will be
automatically sent.
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] kernfs: define kernfs_node_dentry
From: Aditya Kali
Add a new kernfs api is added to lookup the dentry for a particular
kernfs path.
Signed-off-by: Aditya Kali
Signed-off-by: Serge E. Hallyn
---
Changelog:
20151116 - Don't allow user namespaces to bind new subsystems
20151118 - postpone the FS_USERNS_MOUNT flag until the
last patch, until we can convince ourselves it
is safe.
20151207 - Switch to walking up the kernfs path from kn root.
20151208 - Split out the kernfs change
- Style changes
- Switch from pr_crit to WARN_ON
- Reorder arguments to kernfs_obtain_root
- rename kernfs_obtain_root to kernfs_node_dentry
---
fs/kernfs/mount.c | 67
include/linux/kernfs.h |2 ++
2 files changed, 69 insertions(+)
diff --git a/fs/kernfs/mount.c b/fs/kernfs/mount.c
index 8eaf417..7224296 100644
--- a/fs/kernfs/mount.c
+++ b/fs/kernfs/mount.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "kernfs-internal.h"
@@ -62,6 +63,72 @@ struct kernfs_root *kernfs_root_from_sb(struct super_block
*sb)
return NULL;
}
+/*
+ * find the next ancestor in the path down to @child, where @parent was the
+ * ancestor whose descendant we want to find.
+ *
+ * Say the path is /a/b/c/d. @child is d, @parent is NULL. We return the root
+ * node. If @parent is b, then we return the node for c.
+ * Passing in d as @parent is not ok.
+ */
+static struct kernfs_node *
+find_next_ancestor(struct kernfs_node *child, struct kernfs_node *parent)
+{
+ if (child == parent) {
+ pr_crit_once("BUG in find_next_ancestor: called with parent ==
child");
+ return NULL;
+ }
+
+ while (child->parent != parent) {
+ if (!child->parent)
+ return NULL;
+ child = child->parent;
+ }
+
+ return child;
+}
+
+/**
+ * kernfs_node_dentry - get a dentry for the given kernfs_node
+ * @kn: kernfs_node for which a dentry is needed
+ * @sb: the kernfs super_block
+ */
+struct dentry *kernfs_node_dentry(struct kernfs_node *kn,
+ struct super_block *sb)
+{
+ struct dentry *dentry;
+ struct kernfs_node *knparent = NULL;
+
+ BUG_ON(sb->s_op != _sops);
+
+ dentry = dget(sb->s_root);
+
+ /* Check if this is the root kernfs_node */
+ if (!kn->parent)
+ return dentry;
+
+ knparent = find_next_ancestor(kn, NULL);
+ if (WARN_ON(!knparent))
+ return ERR_PTR(-EINVAL);
+
+ do {
+ struct dentry *dtmp;
+ struct kernfs_node *kntmp;
+
+ if (kn == knparent)
+ return dentry;
+ kntmp = find_next_ancestor(kn, knparent);
+ if (WARN_ON(!kntmp))
+ return ERR_PTR(-EINVAL);
+ dtmp = lookup_one_len(kntmp->name, dentry, strlen(kntmp->name));
+ dput(dentry);
+ if (IS_ERR(dtmp))
+ return dtmp;
+ knparent = kntmp;
+ dentry = dtmp;
+ } while (1);
+}
+
static int kernfs_fill_super(struct super_block *sb, unsigned long magic)
{
struct kernfs_super_info *info = kernfs_info(sb);
diff --git a/include/linux/kernfs.h b/include/linux/kernfs.h
index 716bfde..c06c442 100644
--- a/include/linux/kernfs.h
+++ b/include/linux/kernfs.h
@@ -284,6 +284,8 @@ struct kernfs_node *kernfs_node_from_dentry(struct dentry
*dentry);
struct kernfs_root *kernfs_root_from_sb(struct super_block *sb);
struct inode *kernfs_get_inode(struct super_block *sb, struct kernfs_node *kn);
+struct dentry *kernfs_node_dentry(struct kernfs_node *kn,
+ struct super_block *sb);
struct kernfs_root *kernfs_create_root(struct kernfs_syscall_ops *scops,
unsigned int flags, void *priv);
void kernfs_destroy_root(struct kernfs_root *root);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] cgroup: Add documentation for cgroup namespaces
From: Aditya Kali
Signed-off-by: Aditya Kali
Signed-off-by: Serge Hallyn
---
Changelog (2015-12-08):
Merge into Documentation/cgroup.txt
Changelog (2015-12-22):
Reformat to try to follow the style of the rest of the cgroup.txt file.
Signed-off-by: Serge Hallyn
---
Documentation/cgroup.txt | 150 ++
1 file changed, 150 insertions(+)
diff --git a/Documentation/cgroup.txt b/Documentation/cgroup.txt
index 31d1f7b..03ad757 100644
--- a/Documentation/cgroup.txt
+++ b/Documentation/cgroup.txt
@@ -47,6 +47,7 @@ CONTENTS
5-3. IO
5-3-1. IO Interface Files
5-3-2. Writeback
+6. Namespaces
P. Information on Kernel Programming
P-1. Filesystem Support for Writeback
D. Deprecated v1 Core Features
@@ -1013,6 +1014,155 @@ writeback as follows.
vm.dirty[_background]_ratio.
+6. Cgroup Namespaces
+
+Cgroup namespaces provides a mechanism to virtualize the view of the
+"/proc/$PID/cgroup" file. The CLONE_NEWCGROUP clone flag can be used with
+clone() and unshare() syscalls to create a new cgroup namespace. The process
+running inside the cgroup namespace will have its "/proc/$PID/cgroup" output
+restricted to cgroupns root. The cgroupns root is the cgroup of the process at
+the time of creation of the cgroup namespace.
+
+Prior to cgroup namespaces, the "/proc/$PID/cgroup" file showed the complete
+path of the cgroup of a process. In a container setup where a set of cgroups
+and namespaces are intended to isolate processes the "/proc/$PID/cgroup" file
+may leak potential system level information to the isolated processes.
+
+For Example:
+ # cat /proc/self/cgroup
+ 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/container_id1
+
+The path '/batchjobs/container_id1' can generally be considered as system-data
+and its desirable to not expose it to the isolated process.
+
+Cgroup namespaces can be used to restrict visibility of this path.
+For example, before creating a cgroup namespace, one would see:
+
+ # ls -l /proc/self/ns/cgroup
+ lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup ->
cgroup:[4026531835]
+ # cat /proc/self/cgroup
+ 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/container_id1
+
+After unsharing a new namespace, the view has changed.
+
+ # ls -l /proc/self/ns/cgroup
+ lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup ->
cgroup:[4026532183]
+ # cat /proc/self/cgroup
+ 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/
+
+While a task in the global cgroup namespace sees the full path.
+
+ # cat /proc/$PID/cgroup
+ 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/batchjobs/container_id1
+
+If also unsharing the user and mounts namespaces, then when mounting cgroupfs
+then the mount's root will be the task's cgroup.
+
+ # lxc-usernsexec --unshare -m -c
+ # mount -t cgroup cgroup /tmp/cgroup
+ # ls -l /tmp/cgroup
+ total 0
+ -r--r--r-- 1 root root 0 2014-10-13 09:32 cgroup.controllers
+ -r--r--r-- 1 root root 0 2014-10-13 09:32 cgroup.populated
+ -rw-r--r-- 1 root root 0 2014-10-13 09:25 cgroup.procs
+ -rw-r--r-- 1 root root 0 2014-10-13 09:32 cgroup.subtree_control
+
+The cgroupns root (/batchjobs/container_id1 in above example) becomes the
+filesystem root for the namespace specific cgroupfs mount.
+
+The virtualization of /proc/self/cgroup file combined with restricting
+the view of cgroup hierarchy by namespace-private cgroupfs mount
+should provide a completely isolated cgroup view inside the container.
+
+In its current form, the cgroup namespaces patcheset provides following
+behavior:
+
+(1) The 'cgroupns root' for a cgroup namespace is the cgroup in which
+the process calling unshare is running.
+For ex. if a process in /batchjobs/container_id1 cgroup calls unshare,
+cgroup /batchjobs/container_id1 becomes the cgroupns root.
+For the init_cgroup_ns, this is the real root ('/') cgroup
+(identified in code as cgrp_dfl_root.cgrp).
+
+(2) The cgroupns root cgroup does not change even if the namespace
+creator process later moves to a different cgroup.
+# ~/unshare -c # unshare cgroupns in some cgroup
+ # cat /proc/self/cgroup
+ 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/
+ # mkdir sub_cgrp_1
+ # echo 0 > sub_cgrp_1/cgroup.procs
+ # cat /proc/self/cgroup
+ 0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/sub_cgrp_1
+
+(3) Each process gets its namespace-specific view of "/proc/$PID/cgroup"
+
+(a) Processes running inside the cgroup namespace will be able to see
+cgroup paths (in /proc/self/cgroup) only inside their root cgroup.
+From within an unshared cgroupns:
+# sleep 10 &
+[1] 7353
+# echo 7353 > sub_cgrp_1/cgroup.procs
+# cat /proc/7353/cgroup
+0:cpuset,cpu,cpuacct,memory,devices,freezer,hugetlb:/sub_cgrp_1
+
+(b) From the initial cgroup namespace, the real cgroup path will be visible:
+$ cat /proc/7353/cgroup
+
Re: [PATCH v6 13/20] arm64: ilp32: share aarch32 syscall wrappers to ilp32
On Tue, Dec 22, 2015 at 12:25:15PM +, Catalin Marinas wrote: > On Wed, Dec 16, 2015 at 12:42:39AM +0300, Yury Norov wrote: > > statfs64, fstat64 and mmap_pgoff has wrappers that needed both by aarch32 > > and > > ilp32 to workaround some issues. Here we create common file to share aarch32 > > workarounds to with ilp32 code. > [...] > > --- /dev/null > > +++ b/arch/arm64/kernel/entry32-common.S > > @@ -0,0 +1,37 @@ > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > + > > +ENTRY(compat_sys_statfs64_wrapper) > > + mov w3, #84 > > + cmp w1, #88 > > + cselw1, w3, w1, eq > > + b compat_sys_statfs64 > > +ENDPROC(compat_sys_statfs64_wrapper) > > + > > +ENTRY(compat_sys_fstatfs64_wrapper) > > + mov w3, #84 > > + cmp w1, #88 > > + cselw1, w3, w1, eq > > + b compat_sys_fstatfs64 > > +ENDPROC(compat_sys_fstatfs64_wrapper) > > I'm not convinced we need these wrappers for ILP32. They've been > introduced on arch/arm many years ago by commit Fixes: 713c481519f1 > ([ARM] 3108/2: old ABI compat: statfs64 and fstatfs64) to deal with user > space passing a size of 88 (the EABI size of struct compat_statfs64 > without the packing and alignment attribute). Since that commit, the > sizeof(struct compat_statfs64) is 84 already. This should be the case > with the new ILP32 exported headers (no backwards compatibility), so > user space should never pass 88 as size. Therefore we could call > compat_sys_(f)statfs64 directly without wrappers. > With current glibc, sizeof(struct compat_statfs64) is 88, so I added wrappers just to make this couple of syscalls work. AFAIR, glibc doesn't use exported headers here, so we'd change it. Maybe Andrew will share more details. > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply
Hi Jingoo,
On 12/22/2015 08:26 PM, Jingoo Han wrote:
On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
After test on rockchiop platform, i found sometims driver would failed
at reading EDID message. After debugging more, i found that it's okay
to read_a byte from i2c, but it would failed at AUX transcation if we
try to ready multi-bytes from i2c.
Driver just can't received the AUX CH reply command, even no AUX error
code. I may guess that the AUX wait time is not enough, so I try to
expand the AUX wait time, and i do see this could fix the EDID read
failed at rockchip platform.
And I thought that expand the wait time won't hurt Exynos platform too
much, cause Exynos didn't have this problem, then driver would received
the reply command very soon, so no more additional wait time would bring
to Exynos platform.
Signed-off-by: Yakir Yang
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index c7e2959..dc376bd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct
analogix_dp_device *dp)
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
No, I hate this coding.
analogix_dp_reg.c is the common code that can be shared by various SoCs.
Please, find another way.
Okay, I have double checked that i do have this problem in my side.
Hmmm.
I thought it's okay for you if I expand the "DP_TIMEOUT_LOOP_COUNT"
directly,
it won't hurt Exynos platform too much, cause Exynos didn't have this
problem,
then driver would received,the reply command very soon, so no more
additional
wait time would bring to Exynos platform.
And actually the datasheet haven't described the spec of aux reply delay
time.
Thanks,
- Yakir
Best regards,
Jingoo Han
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] cgroup: cgroup namespace setns support
From: Aditya Kali
setns on a cgroup namespace is allowed only if
task has CAP_SYS_ADMIN in its current user-namespace and
over the user-namespace associated with target cgroupns.
No implicit cgroup changes happen with attaching to another
cgroupns. It is expected that the somone moves the attaching
process under the target cgroupns-root.
Signed-off-by: Aditya Kali
Signed-off-by: Serge E. Hallyn
---
kernel/cgroup.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 72336f5..e85fbf9 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5925,10 +5925,28 @@ err_out:
return ERR_PTR(err);
}
-static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
+static inline struct cgroup_namespace *to_cg_ns(struct ns_common *ns)
{
- pr_info("setns not supported for cgroup namespace");
- return -EINVAL;
+ return container_of(ns, struct cgroup_namespace, ns);
+}
+
+static int cgroupns_install(struct nsproxy *nsproxy, struct ns_common *ns)
+{
+ struct cgroup_namespace *cgroup_ns = to_cg_ns(ns);
+
+ if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN) ||
+ !ns_capable(cgroup_ns->user_ns, CAP_SYS_ADMIN))
+ return -EPERM;
+
+ /* Don't need to do anything if we are attaching to our own cgroupns. */
+ if (cgroup_ns == nsproxy->cgroup_ns)
+ return 0;
+
+ get_cgroup_ns(cgroup_ns);
+ put_cgroup_ns(nsproxy->cgroup_ns);
+ nsproxy->cgroup_ns = cgroup_ns;
+
+ return 0;
}
static struct ns_common *cgroupns_get(struct task_struct *task)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] sched: new clone flag CLONE_NEWCGROUP for cgroup namespace
From: Aditya Kali CLONE_NEWCGROUP will be used to create new cgroup namespace. Signed-off-by: Aditya Kali Signed-off-by: Serge Hallyn --- include/uapi/linux/sched.h |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index cc89dde..5f0fe01 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -21,8 +21,7 @@ #define CLONE_DETACHED 0x0040 /* Unused, ignored */ #define CLONE_UNTRACED 0x0080 /* set if the tracing process can't force CLONE_PTRACE on this clone */ #define CLONE_CHILD_SETTID 0x0100 /* set the TID in the child */ -/* 0x0200 was previously the unused CLONE_STOPPED (Start in stopped state) - and is now available for re-use. */ +#define CLONE_NEWCGROUP0x0200 /* New cgroup namespace */ #define CLONE_NEWUTS 0x0400 /* New utsname namespace */ #define CLONE_NEWIPC 0x0800 /* New ipc namespace */ #define CLONE_NEWUSER 0x1000 /* New user namespace */ -- 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/
CGroup Namespaces (v8)
Hi, following is a revised set of the CGroup Namespace patchset which Aditya Kali has previously sent. The code can also be found in the cgroupns.v8 branch of https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/ To summarize the semantics: 1. CLONE_NEWCGROUP re-uses 0x0200, which was previously CLONE_STOPPED 2. unsharing a cgroup namespace makes all your current cgroups your new cgroup root. 3. /proc/pid/cgroup always shows cgroup paths relative to the reader's cgroup namespce root. A task outside of your cgroup looks like 8:memory:/../../.. 4. when a task mounts a cgroupfs, the cgroup which shows up as root depends on the mounting task's cgroup namespace. 5. setns to a cgroup namespace switches your cgroup namespace but not your cgroups. With this, using github.com/hallyn/lxc #2015-11-09/cgns (and github.com/hallyn/lxcfs #2015-11-10/cgns) we can start a container in a full proper cgroup namespace, avoiding either cgmanager or lxcfs cgroup bind mounts. This is completely backward compatible and will be completely invisible to any existing cgroup users (except for those running inside a cgroup namespace and looking at /proc/pid/cgroup of tasks outside their namespace.) Changes from V7: 1. Rework kernfs_path_from_node_locked to return the string length 2. Rename and reorder args to kernfs_path_from_node 3. cgroup.c: undo accidental conversoins to inline 4. cgroup.h: move ns declarations to bottom. 5. Rework the documentation to fit the style of the rest of cgroup.txt Changes from V6: 1. Switch to some WARN_ONs to provide stack traces 2. Rename kernfs_node_distance to kernfs_depth 3. Make sure kernfs_common_ancestor() nodes are from same root 4. Split kernfs changes for cgroup_mount into separate patch 5. Rename kernfs_obtain_root to kernfs_node_dentry (And more, see patch changelogs) Changes from V5: 1. To get a root dentry for cgroup namespace mount, walk the path from the kernfs root dentry. Changes from V4: 1. Move the FS_USERNS_MOUNT flag to last patch 2. Rebase onto cgroup/for-4.5 3. Don't non-init user namespaces to bind new subsystems when mounting. 4. Address feedback from Tejun (thanks). Specificaly, not addressed: . kernfs_obtain_root - walking dentry from kernfs root. (I think that's the only piece) 5. Dropped unused get_task_cgroup fn/patch. 6. Reworked kernfs_path_from_node_locked() to try to simplify the logic. It now finds a common ancestor, walks from the source to it, then back up to the target. Changes from V3: 1. Rebased onto latest cgroup changes. In particular switch to css_set_lock and ns_common. 2. Support all hierarchies. Changes from V2: 1. Added documentation in Documentation/cgroups/namespace.txt 2. Fixed a bug that caused crash 3. Incorporated some other suggestions from last patchset: - removed use of threadgroup_lock() while creating new cgroupns - use task_lock() instead of rcu_read_lock() while accessing task->nsproxy - optimized setns() to own cgroupns - simplified code around sane-behavior mount option parsing 4. Restored ACKs from Serge Hallyn from v1 on few patches that have not changed since then. Changes from V1: 1. No pinning of processes within cgroupns. Tasks can be freely moved across cgroups even outside of their cgroupns-root. Usual DAC/MAC policies apply as before. 2. Path in /proc//cgroup is now always shown and is relative to cgroupns-root. So path can contain '/..' strings depending on cgroupns-root of the reader and cgroup of . 3. setns() does not require the process to first move under target cgroupns-root. Changes form RFC (V0): 1. setns support for cgroupns 2. 'mount -t cgroup cgroup ' from inside a cgroupns now mounts the cgroup hierarcy with cgroupns-root as the filesystem root. 3. writes to cgroup files outside of cgroupns-root are not allowed 4. visibility of /proc//cgroup is further restricted by not showing anything if the is in a sibling cgroupns and its cgroup falls outside your cgroupns-root. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: core: devio.c: Removed unnecessary space
Removed an unnecessary space between a function name and arguments. Signed-off-by: Chase Metzger --- drivers/usb/core/devio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 38ae877c..0bcd45e 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1910,7 +1910,7 @@ static int proc_releaseinterface(struct usb_dev_state *ps, void __user *arg) ret = releaseintf(ps, ifnum); if (ret < 0) return ret; - destroy_async_on_interface (ps, ifnum); + destroy_async_on_interface(ps, ifnum); return 0; } -- 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 v3 68/77] ncr5380: Fix whitespace issues using regexp
On Tue, 22 Dec 2015, Joe Perches wrote: > On Wed, 2015-12-23 at 13:03 +1100, Finn Thain wrote: > > On Tue, 22 Dec 2015, Joe Perches wrote: > > > > > On Wed, 2015-12-23 at 11:56 +1100, Finn Thain wrote: > > > > On Tue, 22 Dec 2015, Joe Perches wrote: > > > > > > > > > On Tue, 2015-12-22 at 12:18 +1100, Finn Thain wrote: > > > > > > This patch is just the result of two substitutions. The first > > > > > > removes any tabs and spaces at the end of the line. The second > > > > > > replaces runs of tabs and spaces at the beginning of comment lines > > > > > > with a single space. > > > > > > > > > > I think the second of these isn't done well. > > > > > > > > The aim of this patch is not to fix code style, but to make it > > > > possible to compare these two files so that the fork can be repaired. > > > > Regexp is very helpful in creating uniformity (and a minimal diff). > > > > > > > > If this was a coding style issue, we would be discussing the use of > > > > kernel-doc format for the affected comments, not whitespace. > > > > > > > > > Many of these comments post reformatting are much worse to read > > > > > because of lost alignment. > > > > > > > > You exaggerate a very trivial point. > > > > > > > > > > > > I prefer that all patches be improvements. > > > > > > > Agreed. But the example you cited is an improvement, in that it creates > > consistency. > > I think "consistency" isn't a useful argument. > The kernel code doesn't care about any other > external code bases. I prefer that the drivers I maintain be self-consistent. > > > Like you, I prefer to see formal parameters aligned when wrapped. But this > > isn't a formal parameter list, it is a comment, and no comment should > > duplicate code. > > > > Can you suggest a better regexp? Since this is patch 68 in the series, > > there is a good chance that it will need to be regenerated. > > I suggest you do 2 patches here. One that removes > unnecessary trailing spaces Those are resolved by this patch. > and converts multiple leading spaces to tabs where appropriate As I said, trivial cleanups are better done after the fork is resolved, to avoid churn. To assist with resolving the fork, this patch addresses inconsistencies. > and a > second patch that fixes whatever odd indentation > that does exist after comment leading *. Those are resolved by this patch. > I think > there aren't many instances of those and I think > those should be done by hand rather than regex. I don't know why a regexp wouldn't work and I don't know what you have in mind when you say "[fix] odd indentation". Is there some kind of style guide applicable here, which this patch violates? Upon re-reading this patch, I did find a table where I think the regexp is detrimental. @@ -2096,7 +2096,7 @@ static void NCR5380_information_transfer * Byte * 0EXTENDED_MESSAGE == 1 * 1length (includes one byte for code, doesn't -* include first two bytes) +* include first two bytes) * 2code * 3..length+1 arguments * This table is interesting. Even though the author took the trouble to duplicate a portion of the SCSI spec in the source, they were still able to stuff it up. See patch 44/77 in this series, "ncr5380: Fix off-by-one bug in extended_msg[] bounds check". So how about I remove this table in patch 67, along with the other dud comments, and then regenerate this patch. That way, perhaps we can all agree that the regexp is not actually detrimental? --
Re: [PATCH 1/7] printk: Hand over printing to console if printing too long
On (12/23/15 12:57), Sergey Senozhatsky wrote:
[..]
> > > can we replace this oops_in_progress check with something more reliable?
> > >
> > > CPU0CPU1 - CPUN
> > > panic()
> > > local_irq_disable()executing foo() with irqs disabled,
> > > console_verbose() or processing an extremely long irq
> > > handler.
> > > bust_spinlocks()
> > > oops_in_progress++
>
> or we huge enough number of CPUs,
> `deep' stack
> traces, slow serial and CPU doing
> dump_stack()
> under raw_spin_lock(_lock), so it
> can take
> longer than 1 second to print the
> stacks and
> thus panic CPU will set
> oops_in_progress back
> to 0.
>
> > > smp_send_stop()
> > >
> > > bust_spinlocks()
> > > oops_in_progress-- ok, IPI arrives
> > > dump_stack()/printk()/etc from
> > > IPI_CPU_STOP
> > > "while (1) cpu_relax()" with irq/fiq
> > > disabled/halt/etc.
> > >
> > > smp_send_stop() wrapped in `oops_in_progress++/oops_in_progress--' is
> > > arch specific,
> > > and some platforms don't do any IPI-delivered (e.g. via
> > > num_online_cpus()) checks at
> > > all. Some do. For example, arm/arm64:
> > >
> > > void smp_send_stop(void)
> > > ...
> > > /* Wait up to one second for other CPUs to stop */
> > > timeout = USEC_PER_SEC;
> > > while (num_online_cpus() > 1 && timeout--)
> > > udelay(1);
> > >
> > > if (num_online_cpus() > 1)
> > > pr_warn("SMP: failed to stop secondary CPUs\n");
> > > ...
> > >
> > >
> > > so there are non-zero chances that IPI will arrive to CPU after
> > > 'oops_in_progress--',
> > > and thus dump_stack()/etc. happening on that/those cpu/cpus will be lost.
> > >
> > >
> > > bust_spinlocks(0) does
> > > ...
> > > if (--oops_in_progress == 0)
> > > wake_up_klogd();
> > > ...
> > >
> > > but local cpu has irqs disabled and `panic_timeout' can be zero.
well, if panic_timeout != 0, then wake_up_klogd() calls irq_work_queue() which
schedule_work. what if we have the following
CPU0CPU1 - CPUN
foo
preempt_disable
bar
panic irq/fiq disable
schedule_work while (1) cpu_relax
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] printk: Hand over printing to console if printing too long
On (12/23/15 12:37), Sergey Senozhatsky wrote:
> Date: Wed, 23 Dec 2015 12:37:24 +0900
> From: Sergey Senozhatsky
> To: Sergey Senozhatsky
> Cc: Jan Kara , Sergey Senozhatsky
> , Andrew Morton ,
> Petr Mladek , KY Sri nivasan , Steven
> Rostedt , linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/7] printk: Hand over printing to console if printing
> too long
> User-Agent: Mutt/1.5.24 (2015-08-30)
>
> On (12/23/15 10:54), Sergey Senozhatsky wrote:
> > On (12/22/15 14:47), Jan Kara wrote:
> > [..]
> > > @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int
> > > level,
> > > logbuf_cpu = UINT_MAX;
> > > raw_spin_unlock(_lock);
> > > lockdep_on();
> > > + /*
> > > + * By default we print message to console asynchronously so that kernel
> > > + * doesn't get stalled due to slow serial console. That can lead to
> > > + * softlockups, lost interrupts, or userspace timing out under heavy
> > > + * printing load.
> > > + *
> > > + * However we resort to synchronous printing of messages during early
> > > + * boot, when oops is in progress, or when synchronous printing was
> > > + * explicitely requested by kernel parameter.
> > > + */
> > > + if (keventd_up() && !oops_in_progress && !sync_print) {
> > > + __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> > > + irq_work_queue(this_cpu_ptr(_up_klogd_work));
> > > + } else
> > > + sync_print = true;
>
> oops, didn't have enough coffee... missed that `else sync_print = true' :(
>
ah, never mind my previous email... it's a local variable, so the very next
printk()
happening right after bust_spinlocks(0) will irq_work_queue(). I'd prefer CPUs
to
print stacks rather than burn cpu cycles in `while (1) cpu_relax()' loop.
so
else {
printk_sync = true;
sync_print = true; /* and remove this local variable entirely may be*/
}
> > can we replace this oops_in_progress check with something more reliable?
> >
> > CPU0CPU1 - CPUN
> > panic()
> > local_irq_disable()executing foo() with irqs disabled,
> > console_verbose() or processing an extremely long irq
> > handler.
> > bust_spinlocks()
> > oops_in_progress++
or we huge enough number of CPUs,
`deep' stack
traces, slow serial and CPU doing
dump_stack()
under raw_spin_lock(_lock), so it
can take
longer than 1 second to print the
stacks and
thus panic CPU will set
oops_in_progress back
to 0.
> > smp_send_stop()
> >
> > bust_spinlocks()
> > oops_in_progress-- ok, IPI arrives
> > dump_stack()/printk()/etc from
> > IPI_CPU_STOP
> > "while (1) cpu_relax()" with irq/fiq
> > disabled/halt/etc.
> >
> > smp_send_stop() wrapped in `oops_in_progress++/oops_in_progress--' is arch
> > specific,
> > and some platforms don't do any IPI-delivered (e.g. via num_online_cpus())
> > checks at
> > all. Some do. For example, arm/arm64:
> >
> > void smp_send_stop(void)
> > ...
> > /* Wait up to one second for other CPUs to stop */
> > timeout = USEC_PER_SEC;
> > while (num_online_cpus() > 1 && timeout--)
> > udelay(1);
> >
> > if (num_online_cpus() > 1)
> > pr_warn("SMP: failed to stop secondary CPUs\n");
> > ...
> >
> >
> > so there are non-zero chances that IPI will arrive to CPU after
> > 'oops_in_progress--',
> > and thus dump_stack()/etc. happening on that/those cpu/cpus will be lost.
> >
> >
> > bust_spinlocks(0) does
> > ...
> > if (--oops_in_progress == 0)
> > wake_up_klogd();
> > ...
> >
> > but local cpu has irqs disabled and `panic_timeout' can be zero.
> >
> > How about setting 'sync_print' to 'true' in...
> > bust_spinlocks() /* only set to true */
> > or
> > console_verbose() /* um... may be... */
> > or
> > having a separate one-liner for that
> >
> > void console_panic_mode(void)
> > {
> > sync_print = true;
printk_sync = true;
> > }
> >
> > and call it early in panic(), before we send out IPI_STOP.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 23
Hi all, News: there will (probably) be no linux-next releases until Jan 4 (unless I get bored). Changes since 20151222: The i2c tree still had its build failure for which I applied a patch. The drm tree gained a conflict against the drm-intel-fixes tree. I added a supplied patch to the akpm-current tree to fix a widespread build problem. Non-merge commits (relative to Linus' tree): 7403 7560 files changed, 303707 insertions(+), 123529 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4ef7675344d6 Linux 4.4-rc6) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (07fd7d4bbcb9 ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE) Merging arm-current/fixes (34bfbae33ae8 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (036592fbbe75 powerpc/opal-irqchip: Fix deadlock introduced by "Fix double endian conversion") Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73796d8bf273 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (5cbf20c74798 sh_eth: fix 16-bit descriptor field access endianness too) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (01d85b9b2b6b Merge tag 'iwlwifi-for-kalle-2015-12-16' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (cf1e05c63642 mac80211: handle width changes from opmode notification IE in beacon) Merging sound-current/for-linus (9f660a1c4389 ALSA: hda/realtek - Fix silent headphone output on MacPro 4,1 (v2)) Merging pci-current/for-linus (1dbe162d53e1 PCI: hisi: Fix hisi_pcie_cfg_read() 32-bit reads) Merging driver-core.current/driver-core-linus (4ef7675344d6 Linux 4.4-rc6) Merging tty.current/tty-linus (4ef7675344d6 Linux 4.4-rc6) Merging usb.current/usb-linus (4ef7675344d6 Linux 4.4-rc6) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (9f9499ae8e64 Linux 4.4-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9f9499ae8e64 Linux 4.4-rc5) Merging char-misc.current/char-misc-linus (9f9499ae8e64 Linux 4.4-rc5) Merging input-current/for-linus (478e5ed1c3f6 Input: elants_i2c - fix wake-on-touch) Merging crypto-current/master (0d96e4bab285 crypto: algif_skcipher - Use new skcipher interface) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio
[PATCH v6.3 4/6] drm: rockchip: Support Synopsys DW MIPI DSI
Add support for Synopsys DesignWare MIPI DSI controller which is embedded in the rk3288 SoCs. Signed-off-by: Chris Zhong --- Changes in v6.3: - move the mipi_en gate to ockchip_drm_crtc_mode_config Changes in v6.2: - Remove the atomic feature check (Mark Yao) Changes in v6.1: - Add atomic API support (Heiko Stübne) Changes in v6: - Do not use bridge driver (Thierry Reding) - Optimization the phy init sequence Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1196 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + 4 files changed, 1210 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 686cb49..1db1b86 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -34,3 +34,13 @@ config ROCKCHIP_ANALOGIX_DP This selects support for Rockchip SoC specific extensions for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. + +config ROCKCHIP_DW_MIPI_DSI + bool "Rockchip specific extensions for Synopsys DW MIPI DSI" + depends on DRM_ROCKCHIP + select DRM_MIPI_DSI + help +This selects support for Rockchip SoC specific extensions +for the Synopsys DesignWare HDMI driver. If you want to +enable MIPI DSI on RK3288 based SoC, you should selet this +option. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 8ad01fb..c5c2d61 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,5 +7,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \ obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c new file mode 100644 index 000..1fe631e --- /dev/null +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c @@ -0,0 +1,1196 @@ +/* + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define DRIVER_NAME"dw-mipi-dsi" + +#define GRF_SOC_CON60x025c +#define DSI0_SEL_VOP_LIT(1 << 6) +#define DSI1_SEL_VOP_LIT(1 << 9) + +#define DSI_VERSION0x00 +#define DSI_PWR_UP 0x04 +#define RESET 0 +#define POWERUPBIT(0) + +#define DSI_CLKMGR_CFG 0x08 +#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) + +#define DSI_DPI_VCID 0x0c +#define DPI_VID(vid) (((vid) & 0x3) << 0) + +#define DSI_DPI_COLOR_CODING 0x10 +#define EN18_LOOSELY BIT(8) +#define DPI_COLOR_CODING_16BIT_1 0x0 +#define DPI_COLOR_CODING_16BIT_2 0x1 +#define DPI_COLOR_CODING_16BIT_3 0x2 +#define DPI_COLOR_CODING_18BIT_1 0x3 +#define DPI_COLOR_CODING_18BIT_2 0x4 +#define DPI_COLOR_CODING_24BIT 0x5 + +#define DSI_DPI_CFG_POL0x14 +#define COLORM_ACTIVE_LOW BIT(4) +#define SHUTD_ACTIVE_LOW BIT(3) +#define HSYNC_ACTIVE_LOW BIT(2) +#define VSYNC_ACTIVE_LOW BIT(1) +#define DATAEN_ACTIVE_LOW BIT(0) + +#define DSI_DPI_LP_CMD_TIM 0x18 +#define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) +#define INVACT_LPCMD_TIME(p) ((p) & 0xff) + +#define DSI_DBI_CFG0x20 +#define DSI_DBI_CMDSIZE0x28 + +#define DSI_PCKHDL_CFG 0x2c +#define EN_CRC_RX BIT(4) +#define EN_ECC_RX BIT(3) +#define EN_BTA BIT(2) +#define EN_EOTP_RX BIT(1) +#define EN_EOTP_TX BIT(0) + +#define DSI_MODE_CFG 0x34 +#define ENABLE_VIDEO_MODE 0 +#define ENABLE_CMD_MODEBIT(0) + +#define DSI_VID_MODE_CFG 0x38
Re: [PATCH 1/7] printk: Hand over printing to console if printing too long
On (12/23/15 10:54), Sergey Senozhatsky wrote:
> On (12/22/15 14:47), Jan Kara wrote:
> [..]
> > @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int level,
> > logbuf_cpu = UINT_MAX;
> > raw_spin_unlock(_lock);
> > lockdep_on();
> > + /*
> > +* By default we print message to console asynchronously so that kernel
> > +* doesn't get stalled due to slow serial console. That can lead to
> > +* softlockups, lost interrupts, or userspace timing out under heavy
> > +* printing load.
> > +*
> > +* However we resort to synchronous printing of messages during early
> > +* boot, when oops is in progress, or when synchronous printing was
> > +* explicitely requested by kernel parameter.
> > +*/
> > + if (keventd_up() && !oops_in_progress && !sync_print) {
> > + __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> > + irq_work_queue(this_cpu_ptr(_up_klogd_work));
> > + } else
> > + sync_print = true;
oops, didn't have enough coffee... missed that `else sync_print = true' :(
-ss
> > local_irq_restore(flags);
>
> can we replace this oops_in_progress check with something more reliable?
>
> CPU0CPU1 - CPUN
> panic()
> local_irq_disable()executing foo() with irqs disabled,
> console_verbose() or processing an extremely long irq
> handler.
> bust_spinlocks()
> oops_in_progress++
>
> smp_send_stop()
>
> bust_spinlocks()
> oops_in_progress-- ok, IPI arrives
> dump_stack()/printk()/etc from
> IPI_CPU_STOP
> "while (1) cpu_relax()" with irq/fiq
> disabled/halt/etc.
>
> smp_send_stop() wrapped in `oops_in_progress++/oops_in_progress--' is arch
> specific,
> and some platforms don't do any IPI-delivered (e.g. via num_online_cpus())
> checks at
> all. Some do. For example, arm/arm64:
>
> void smp_send_stop(void)
> ...
> /* Wait up to one second for other CPUs to stop */
> timeout = USEC_PER_SEC;
> while (num_online_cpus() > 1 && timeout--)
> udelay(1);
>
> if (num_online_cpus() > 1)
> pr_warn("SMP: failed to stop secondary CPUs\n");
> ...
>
>
> so there are non-zero chances that IPI will arrive to CPU after
> 'oops_in_progress--',
> and thus dump_stack()/etc. happening on that/those cpu/cpus will be lost.
>
>
> bust_spinlocks(0) does
> ...
> if (--oops_in_progress == 0)
> wake_up_klogd();
> ...
>
> but local cpu has irqs disabled and `panic_timeout' can be zero.
>
> How about setting 'sync_print' to 'true' in...
> bust_spinlocks() /* only set to true */
> or
> console_verbose() /* um... may be... */
> or
> having a separate one-liner for that
>
> void console_panic_mode(void)
> {
> sync_print = true;
> }
>
> and call it early in panic(), before we send out IPI_STOP.
>
> -ss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] r8152: fix lockup when runtime PM is enabled
Oliver Neukum [mailto:oneu...@suse.com] [...] > It is clear to me that you cannot get away with using the same operation > for resume() and reset_resume() in your driver. It is fundamentally > impossible. Firmware cannot fix it. I would think how to fix it. > Sorry for the length of the explanation. Thanks for your response. I have some questions. What are the flows when the system resume follows a system suspend which follows a autosuspend? Are they as following? 1. suspend() with PMSG_IS_AUTO for autosuspned. 2. suspend() for system suspend. 3. resume() for system resume. And, should the device exist autosuspend before (2)? Best Regards, Hayes
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
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. > We might have "discussed" this ;-) As I proposed this would go to the powerpc next in this mail: http://marc.info/?l=linux-kernel=144660021417639=2 Regards, Boqun > 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. > > cheers > signature.asc Description: PGP signature
RE: [f2fs-dev] [PATCH 2/4] f2fs: avoid unnecessary f2fs_gc for dir operations
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, December 23, 2015 9:00 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 2/4] f2fs: avoid unnecessary f2fs_gc for dir
> operations
>
> The f2fs_balance_fs doesn't need to cover f2fs_new_inode or f2fs_find_entry
> works.
So this avoids some unneeded overhead in f2fs_balance_fs for scenario where
f2fs_new_inode and f2fs_find_entry will fail for most of the time?
Shouldn't cover f2fs_find_entry in rename or rename2 case?
Thanks,
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/namei.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 2c32110..8d2616f 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -128,8 +128,6 @@ static int f2fs_create(struct inode *dir, struct dentry
> *dentry, umode_t
> mode,
> nid_t ino = 0;
> int err;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -142,6 +140,8 @@ static int f2fs_create(struct inode *dir, struct dentry
> *dentry, umode_t
> mode,
> inode->i_mapping->a_ops = _dblock_aops;
> ino = inode->i_ino;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -288,12 +288,13 @@ static int f2fs_unlink(struct inode *dir, struct dentry
> *dentry)
> int err = -ENOENT;
>
> trace_f2fs_unlink_enter(dir, dentry);
> - f2fs_balance_fs(sbi);
>
> de = f2fs_find_entry(dir, >d_name, );
> if (!de)
> goto fail;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = acquire_orphan_inode(sbi);
> if (err) {
> @@ -341,8 +342,6 @@ static int f2fs_symlink(struct inode *dir, struct dentry
> *dentry,
> if (len > dir->i_sb->s_blocksize)
> return -ENAMETOOLONG;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, S_IFLNK | S_IRWXUGO);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -353,6 +352,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry
> *dentry,
> inode->i_op = _symlink_inode_operations;
> inode->i_mapping->a_ops = _dblock_aops;
>
> + f2fs_balance_fs(sbi);
> +
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> if (err)
> @@ -433,8 +434,6 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
> *dentry, umode_t
> mode)
> struct inode *inode;
> int err;
>
> - f2fs_balance_fs(sbi);
> -
> inode = f2fs_new_inode(dir, S_IFDIR | mode);
> if (IS_ERR(inode))
> return PTR_ERR(inode);
> @@ -444,6 +443,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
> *dentry, umode_t
> mode)
> inode->i_mapping->a_ops = _dblock_aops;
> mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_HIGH_ZERO);
>
> + f2fs_balance_fs(sbi);
> +
> set_inode_flag(F2FS_I(inode), FI_INC_LINK);
> f2fs_lock_op(sbi);
> err = f2fs_add_link(dentry, inode);
> --
> 2.5.4 (Apple Git-61)
>
>
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support
Hi, Andy > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Andy Lutomirski > Sent: Wednesday, December 23, 2015 6:49 AM > Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() support > > On Mon, Dec 21, 2015 at 5:03 PM, Chen, Yu C wrote: > > Hi Andy, > > thanks for your review, > > > >> -Original Message- > >> From: Andy Lutomirski [mailto:l...@amacapital.net] > >> Sent: Friday, December 18, 2015 1:00 AM > >> To: Zheng, Lv > >> Cc: Chen, Yu C; Moore, Robert; Wysocki, Rafael J; Brown, Len; Andy > >> Lutomirski; Lv Zheng; linux-kernel@vger.kernel.org; Linux ACPI; H. Peter > >> Anvin; Borislav Petkov > >> Subject: Re: [PATCH v4 7/7] ACPI / x86: introduce acpi_os_readable() > support > >> > > [cut] > >> > >> I think that hpa or Borislav [cc'd] could address the memory map details > >> better than I could. However, this functionality seems strange. > >> > >> Are these physical addresses or virtual addresses that are being dumped? > > [Yu] They are virtual addresses to be dumped. > >> In either case, ISTM that using something iike page_is_ram might be a lot > >> simpler. > > [Yu] if i understand correctly, this API is used to check if the address is > > a valid > > 'kmalloc' style address, but not 'kmap' or 'vmalloc' address, and > > page_is_ram > > might treat the latter as valid address? > > > > I'm a bit puzzled as to why this matters, but I have no fundamental objection > to doing it that way. [Lv Zheng] IMO, using page_is_ram() or something similar, the problem is what we need to solve in the current approach still need to be solved: 1. How can we convert a virtual address into a "struct page"? There is no kernel API to convert any virtual address into struct page. Even there is such a kernel API to convert kmap/vmalloc addresses, we still couldn't use it. Because if we want to validate kmap/vmaloc pages, we need 2 APIs rather than 1 API while ACPICA only provides 1 API for this purpose. The 2 APIs should be get/put style to ping the page mappings as the mappings other than the direct mappings will not be stationary in the kernel address space. Fortunately we needn't take care of the mappings other than the direct mappings (reasons are in the 2nd comment). So we still need to use the direct mapping APIs here. 2. How can we ensure the page is a direct mapping page? I think Yu should confirm if there is such a common kernel API. If there is such an API, we should use it so that we can remove the arch specific stuffs. > What's the use case, though? [Lv Zheng] Fortunately, currently ACPICA only uses this API to validate if a namespace node, an operand object or a parser object is readable. See drivers/acpi/acpica/dbdisplay.c and drivers/acpi/acpica/dbcmds.c. > That is, what goes wrong if the function just always returns false? [Lv Zheng] 1. If it always returns false, then many ACPICA debugger internal object conversion/dump functionalities won't be functioning. For example, you can try to type “dump \_SB" in acpidbg shell and it will return an error: "Invalid named object at address " 2. While if this function always returns true (current linux-pm/linux-next merged stuffs), we can see such a result: Object () Pathname: \_SB Name : _SB_ Type : 06 [Device] ... 3. But if it always returns true, then there will be another problem: User can type an invalid address, for example, "dump 0x". And ACPICA debugger will try to access this invalid virtual address and finally result in a panic. So we need to implement acpi_os_readable() to harden the check. [Lv Zheng] Let me say more about this patch. Currently this patch looks wrong. Though, most of the acpi_object(s) are kmalloced in the kernel heap, as far as I know, at least the namespace root is a statically allocated object in ACPICA. Maybe "One"/"Ones"/"Zero" operands are all statically allocated objects. So we need to modify this function to return true for the addresses that belong to .data/.bss sections for x86_64 kernels. You can confirm this by typing "dump \" in the acpidbg shell, it now returns: "Invalid named object at address 8xxx". We'll update it and send it after testing. Thanks and best regards -Lv
Re: [Propose] Isolate core_pattern in mnt namespace.
On 12/22/2015 05:52 AM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/20/2015 05:47 PM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/20/2015 10:37 AM, Al Viro wrote: On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace. What do you think about it? Hi Eric, I found your patch about "net: Implement the per network namespace sysctl infrastructure", I want to do the similar thing in mnt namespace. Is that suggested way? Why mnt namespace and not something else? Hi Al, Well, because core_pattern indicates the path to store core file. In different mnt namespace, we would like to change the path with different value. In addition, Let's considering other namespaces: UTS ns: contains informations of kernel and arch, not proper for core_pattern. IPC ns: communication informations, not proper for core_pattern PID ns: core_pattern is not related with pid net ns: obviousely no. user ns: not proper too. Then I believe it's better to do this in mnt namespace. of course, core_pattern is just one example. After this infrastructure finished, we can implement more sysctls as per-mnt if necessary, I think. Al, what do you think about this idea? The hard part is not the sysctl. The hard part is starting the usermode helper, in an environment that it can deal with. The mount namespace really provides you with no help there. Do you mean the core dump helper? But I think I don't want to touch it in my development. I think I can use non-pipe way to get what I want, Let me try to explain what I want here. (1). introduce a --core-path option in docker run command to specify the path in host to store core file in one container. E.g: docker run --core-path=/core/test --name=test IMAGE (2). When the container starting, docker attach a volume to it, similar with "-v /core/test:/var/lib/docker/coredump". That means, the path of /var/lib/docker/coredump in container is a link to /core/test in host. (3). Set the /proc/sys/kernel/core_pattern in container as "/var/lib/docker/coredump". But that should not affect the core_pattern in host or other containers. Then I think I can collect the core files from each container and save them in the paths where I want. For your case that sounds like it would work. Unfortunately for this to be generally applicable and to let the OS in the contianer control it's fate the core dump pattern needs to be supported. Otherwise something clever in userspace that can be written now should be sufficient to fill the gap. There is enough information for the user mode helper to implement the policy you would like today. Hi Eric, To make sure I understand your point correctly： Do you mean we can write a userspace helper in host such as /usr/libexec/docker-pipe to get what I want? Yes, I would say, for my case, it would work. This helper can get the dump data from containers and dispatch them to different path such as /var/lib/docker/cores//. But there would be two problems in this solution. (1). It may affect core dump on host. Normally, other processes in host would not be happy to use a helper of docker-pipe for themselves. But host have to share the core_pattern with containers, can't config it by itself. (2). If there are some containers don't want to pass the core files to host, they can't set the core_pattern in this solution. IMO, we can get core files on host currently, by either non-pipe way I described above or the pipe way you suggested. But the problem is both of these methods would affect the core_pattern on host and other containers. So, I think the key point here is just isolating the core dump related sysctl in mnt namespace. Thanx Yang Eric . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Propose] Isolate core_pattern in mnt namespace.
On 12/22/2015 11:12 AM, Kamezawa Hiroyuki wrote: > On 2015/12/22 6:52, Eric W. Biederman wrote: >> Dongsheng Yang writes: >> >>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote: Dongsheng Yang writes: > On 12/20/2015 10:37 AM, Al Viro wrote: >> On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote: >>> On 12/17/2015 07:23 PM, Dongsheng Yang wrote: Hi guys, We are working on making core dump behaviour isolated in container. But the problem is, the /proc/sys/kernel/core_pattern is a kernel wide setting, not belongs to a container. So we want to add core_pattern into mnt namespace. What do you think about it? >>> >>> Hi Eric, >>> I found your patch about "net: Implement the per network >>> namespace >>> sysctl infrastructure", I want to do the similar thing >>> in mnt namespace. Is that suggested way? >> >> Why mnt namespace and not something else? > > Hi Al, > > Well, because core_pattern indicates the path to store core file. > In different mnt namespace, we would like to change the path with > different value. > > In addition, Let's considering other namespaces: > UTS ns: contains informations of kernel and arch, not proper for > core_pattern. > IPC ns: communication informations, not proper for core_pattern > PID ns: core_pattern is not related with pid > net ns: obviousely no. > user ns: not proper too. > > Then I believe it's better to do this in mnt namespace. of course, > core_pattern is just one example. After this infrastructure finished, > we can implement more sysctls as per-mnt if necessary, I think. > > Al, what do you think about this idea? The hard part is not the sysctl. The hard part is starting the usermode helper, in an environment that it can deal with. The mount namespace really provides you with no help there. >>> >>> Do you mean the core dump helper? But I think I don't want to touch it >>> in my development. I think I can use non-pipe way to get what I want, >>> Let me try to explain what I want here. >>> >>> (1). introduce a --core-path option in docker run command to specify the >>> path in host to store core file in one container. >>> E.g: docker run --core-path=/core/test --name=test IMAGE >>> >>> (2). When the container starting, docker attach a volume to it, similar >>> with "-v /core/test:/var/lib/docker/coredump". That means, the path of >>> /var/lib/docker/coredump in container is a link to /core/test in host. >>> >>> (3). Set the /proc/sys/kernel/core_pattern in container as >>> "/var/lib/docker/coredump". But that should not affect the core_pattern >>> in host or other containers. >>> >>> Then I think I can collect the core files from each container and save >>> them in the paths where I want. >> >> For your case that sounds like it would work. Unfortunately for this to >> be generally applicable and to let the OS in the contianer control it's >> fate the core dump pattern needs to be supported. >> >> Otherwise something clever in userspace that can be written now should >> be sufficient to fill the gap. There is enough information for the user >> mode helper to implement the policy you would like today. >> > Let me clarify my understanding. > > 1) running user-mode-helper in a container. > It's not supported by the kernel. user-mode-helper always works on a host. > > 2) running user mode helper in a host. >It's supported in the newest distro(FC23). (abrt supports container.) >Summary is here. https://github.com/abrt/abrt/wiki/Containers-and-chroots > > If a guest user doesn't want to pass a core to the host owner, core_pattern > should be configurable but it can't. Agreed, then we have to make the core_pattern namespace-ed in mnt namespace. Thanx Yang > > Thanks, > -Kame > > > > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [f2fs-dev] [PATCH 1/4] f2fs: check inline_data flag at converting time
> -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Wednesday, December 23, 2015 9:00 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Cc: Jaegeuk Kim > Subject: [f2fs-dev] [PATCH 1/4] f2fs: check inline_data flag at converting > time > > We can check inode's inline_data flag when calling to convert it. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
On 2015/12/23 3:52, rkrc...@redhat.com wrote:
2015-12-22 07:19+, Wu, Feng:
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
On 2015/12/22 14:59, Wu, Feng wrote:
From: Yang Zhang [mailto:yang.zhang...@gmail.com]
On 2015/12/16 9:37, Feng Wu wrote:
+ for_each_set_bit(i, , 16) {
+ if (!dst[i]
&& !kvm_lapic_enabled(dst[i]->vcpu)) {
It should be or(||) not and (&&).
Oh, you are right! My negligence! Thanks for pointing this out, Yang!
btw, i think the kvm_lapic_enabled check is wrong here? Why need it here?
If the lapic is not enabled, I think we cannot recognize it as a candidate, can
we?
Maybe Radim can confirm this, Radim, what is your option?
SDM 10.6.2.2 Logical Destination Mode:
For both configurations of logical destination mode, when combined
with lowest priority delivery mode, software is responsible for
ensuring that all of the local APICs included in or addressed by the
IPI or I/O subsystem interrupt are present and enabled to receive the
interrupt.
The case is undefined if some targeted LAPICs weren't hardware enabled
as no interrupts can be delivered to hardware disabled LAPIC, so we can
check for hardware enabled.
It's not obvious if "enabled to receive the interrupt" means hardware or
software enabled, but lowest priority cannot deliver NMI/INIT/..., so
checking for software enabled doesn't restrict any valid uses either.
Agree. My understanding is that it is software's responsibility to
ensuring this case not happen. But for hypervisor, we should not check
it for software. What we can do is just follow the SDM.
so ... KVM only musn't blow up when encountering this situation :)
The current code seems correct, but redundant. Just for reference, KVM
now does:
- check for software enabled LAPIC since patch aefd18f01ee8 ("KVM: x86:
In DM_LOWEST, only deliver interrupts to vcpus with enabled LAPIC's")
- check only for hardware enabled LAPIC in the fast path, since
1e08ec4a130e ("KVM: optimize apic interrupt delivery"))
(v1 was arguable better, I pointed the need for enabled LAPIC in v1 only
from looking at one KVM function, sorry.)
Lapic can be disable by hw or sw. Here we only need to check the hw is
enough which is already covered while injecting the interrupt into
guest. I remember we(Glab, Macelo and me) have discussed it several ago,
but i cannot find the mail thread.
But if the lapic is disabled by software, we cannot still inject interrupts to
it, can we?
Yes, We cannot inject the normal interrupt. But this already covered by
current logic and add a check here seems meaningless. Conversely, it may
do bad thing..
Let's wait for Radim/Paolo's opinions about this.
I'd pick whatever results in less code: this time it seems like checking
for hardware enabled LAPIC in both paths (implicitly in the fast path).
Maybe it can be done better, I haven't given it much thought.
We should revert aefd18f01ee8 at the same time, so our PI/non-PI slow
paths won't diverge -- I hope it wasn't fixing a bug :)
I'll review the series tomorrow, thanks for your patience.
--
best regards
yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: Revert "dmaengine: mic_x100: add missing spin_unlock"
This reverts commit e958e079e254 ("dmaengine: mic_x100: add missing
spin_unlock").
The above patch is incorrect. There is nothing wrong with the original
code. The spin_lock is acquired in the "prep" functions and released
in "submit".
Signed-off-by: Ashutosh Dixit
---
drivers/dma/mic_x100_dma.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c
index cddfa8d..068e920 100644
--- a/drivers/dma/mic_x100_dma.c
+++ b/drivers/dma/mic_x100_dma.c
@@ -317,7 +317,6 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch, dma_addr_t
dma_dest,
struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
struct device *dev = mic_dma_ch_to_device(mic_ch);
int result;
- struct dma_async_tx_descriptor *tx = NULL;
if (!len && !flags)
return NULL;
@@ -325,13 +324,10 @@ mic_dma_prep_memcpy_lock(struct dma_chan *ch, dma_addr_t
dma_dest,
spin_lock(_ch->prep_lock);
result = mic_dma_do_dma(mic_ch, flags, dma_src, dma_dest, len);
if (result >= 0)
- tx = allocate_tx(mic_ch);
-
- if (!tx)
- dev_err(dev, "Error enqueueing dma, error=%d\n", result);
-
+ return allocate_tx(mic_ch);
+ dev_err(dev, "Error enqueueing dma, error=%d\n", result);
spin_unlock(_ch->prep_lock);
- return tx;
+ return NULL;
}
static struct dma_async_tx_descriptor *
@@ -339,14 +335,13 @@ mic_dma_prep_interrupt_lock(struct dma_chan *ch, unsigned
long flags)
{
struct mic_dma_chan *mic_ch = to_mic_dma_chan(ch);
int ret;
- struct dma_async_tx_descriptor *tx = NULL;
spin_lock(_ch->prep_lock);
ret = mic_dma_do_dma(mic_ch, flags, 0, 0, 0);
if (!ret)
- tx = allocate_tx(mic_ch);
+ return allocate_tx(mic_ch);
spin_unlock(_ch->prep_lock);
- return tx;
+ return NULL;
}
/* Return the status of the transaction */
--
2.0.0.rc3.2.g998f840
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: comedi: fix block comments coding style issue in comedi.h
Dear Greg
I have sent my first patch (https://lkml.org/lkml/2015/11/18/239) to
linux-next tree.But I never received anything about it.So I sent it
again. You say "Doesn't apply to my tree :(".but it can be apply to
least linux-next branch .
I make n new patch and send it.I receive
review(https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1048115.html)
.
I want to know what's wrong with me?
how do I know that my patch is accepted?
2015-12-22 8:02 GMT+08:00 Greg KH :
> On Mon, Dec 14, 2015 at 03:41:10PM +0800, maomao xu wrote:
>> Fix up block comments to make a trailing */ on a separate line
>>
>> Signed-off-by: maomao xu
>> ---
>> drivers/staging/comedi/comedi.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Doesn't apply to my tree :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: warn once for cloned bio in bio_for_each_segment_all()
For one cloned bio, kernel shouldn't touch all segments of this bio via the helper, because the bvec table is shared among all related bios, so warn once for this usage. This change should catch recent memory corruption issue, which is fixed by 23688bf4f830(block: ensure to split after potentially bouncing a bio). Signed-off-by: Ming Lei --- include/linux/bio.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/bio.h b/include/linux/bio.h index b9b6e04..b4a298d 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -191,6 +191,7 @@ static inline void *bio_data(struct bio *bio) * before it got to the driver and the driver won't own all of it */ #define bio_for_each_segment_all(bvl, bio, i) \ + WARN_ON_ONCE(bio_flagged(bio, BIO_CLONED)); \ for (i = 0, bvl = (bio)->bi_io_vec; i < (bio)->bi_vcnt; i++, bvl++) static inline void bvec_iter_advance(struct bio_vec *bv, struct bvec_iter *iter, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] File system corruption with 4.4-rc3 and beyond
On Tue, 22 Dec 2015 20:20:00 -0500 Steven Rostedt wrote: > This test takes over 8 hours (although the i386 portion is less than an > hour). If it finishes with no problems other than my own, I'll let you > know. The i386 portion just finished, and it showed no indication of any errors. So it looks to me that this fixed the issue I was having. Although its too late... Tested-by: Steven Rostedt -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants
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. 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: [PATCH 1/1] powerpc/irq: tidy up inconsistent context in migrate_irqs()
Hi, Denis Any test result on pmac machine for this patch? Zhuoyu > -Original Message- > From: Zhang Zhuoyu [mailto:zhangzhu...@cmss.chinamobile.com] > Sent: Wednesday, December 16, 2015 10:46 PM > To: 'Denis Kirjanov'; 'Michael Ellerman' > Cc: 'Daniel Axtens'; 'Zhang Zhuoyu'; 'b...@kernel.crashing.org'; > 'pau...@samba.org'; 't...@linutronix.de'; 'jiang@linux.intel.com'; > 'linuxppc-...@lists.ozlabs.org'; 'linux-kernel@vger.kernel.org' > Subject: RE: [PATCH 1/1] powerpc/irq: tidy up inconsistent context in > migrate_irqs() > > > > -Original Message- > > From: Denis Kirjanov [mailto:k...@linux-powerpc.org] > > Sent: Wednesday, December 16, 2015 7:55 PM > > To: Michael Ellerman > > Cc: Daniel Axtens; Zhang Zhuoyu; b...@kernel.crashing.org; > > pau...@samba.org; t...@linutronix.de; jiang@linux.intel.com; > > zhangzhu...@cmss.chinamobile.com; linuxppc-...@lists.ozlabs.org; > > linux- ker...@vger.kernel.org > > Subject: Re: [PATCH 1/1] powerpc/irq: tidy up inconsistent context in > > migrate_irqs() > > > > On 12/16/15, Michael Ellerman wrote: > > > On Wed, 2015-12-16 at 17:08 +1100, Daniel Axtens wrote: > > >> Hi, > > >> > > >> A couple of things. > > >> > > >> Firstly, your two email addresses don't match: > > >> > > >> Zhang Zhuoyu writes: > > > > > >> > From: Zhang Zhuoyu > > >> > > Mmm, My mistake, I will correct it next time. > > > >> These lines do seem odd! Are they causing a problem? > > >> > > >> I'd be more comfortable removing them if I understood why they were > > >> added. But they've been around since the beginning of git history > > >> so that could be a bit difficult. > > > > > > It's in the fullhist tree, but that doesn't tell us much (below, > > > named fixup_irqs()). > > > > > > But I suspect those lines are actually there very deliberately. > > > > > > The function is migrating interrupts off the recently offlined cpu, > > > because we don't want to take interrupts on an offline cpu. > > > > > > After it's finished doing the migration, it wants to make sure there > > > are no interrupts that have already been latched by the offline cpu. > > > So it briefly enables interrupts, waits a bit for the interrupts to > > > fire, and the disables them again. > > > > > > Whether that actually works I couldn't say, it is very old code, and > > > it's used on platforms where I don't ever test cpu hotplug (85xx & > > > powermac). > > > > Yeah, it would be nice to test this change. I'll try it on my > > quad-core pmac machine > > > > Thanks Michael for help explaining the code logic, it also resolved my doubts. > These snippets are suspected when I did PM benchmark on FSL MPC85xx > series(T1040, T4240), For T4240, which has 24 CPUs, it waits 1ms in > migrate_irqs()each time a CPU is plugged offline, it seems a waste of time. I > also did a test on T1040, after plugging offline/online CPU hundreds of times, > system works well. If you have any other suggestion on how to test, I'd like > to do more benchmark. > (1)for((i=0; i<1000; i++)); do echo 0 > /sys/devices/system/cpu/cpu1/online; > sleep 1; echo 1 > /sys/devices/system/cpu/cpu1/online; done > (2)root@t1040rdb:~# cat /proc/interrupts >CPU0 CPU1 CPU2 CPU3 > 36:393 1223 1 OpenPIC36 Level > serial > LOC: 1946 1486 1555 1361 Local timer interrupts > DBL: 7371 9707 9390 7568 Doorbell interrupts > (3)root@t1040rdb:~# ps > PID TTY TIME CMD > 2751 ttyS000:00:00 sh > 2757 ttyS000:00:00 ps > root@t1040rdb:~# taskset -pc 1 2751 > pid 2751's current affinity list: 0-3 > pid 2751's new affinity list: 1 > root@t1040rdb:~# > root@t1040rdb:~# > root@t1040rdb:~# > root@t1040rdb:~# echo "hello" > hello > root@t1040rdb:~# > > > > > > > cheers > > > > > > > > > commit d58830b9a740ad1c3b089196d4afdaea251dc701 > > > Author: Zwane Mwaikambo > > > Date: Fri Mar 4 17:34:00 2005 -0800 > > > > > > [PATCH] ppc64: generic hotplug cpu support > > > > > > Patch provides a generic hotplug cpu implementation, with the > > > only current > > > user being pmac. This doesn't replace real hotplug code as is > > > currently > > > used by LPAR systems. Ben i can add the additional pmac > > > specific code to > > > put the processor into a sleeping state seperately. Thanks to > > > Nathan for > > > testing. > > > > > > Signed-off-by: Zwane Mwaikambo > > > Signed-off-by: Andrew Morton > > > Signed-off-by: Linus Torvalds > > > > > > diff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig index > > > a7933ab62e98..861f4460ad02 100644 > > > --- a/arch/ppc64/Kconfig > > > +++ b/arch/ppc64/Kconfig > > > @@ -313,7 +313,7 @@ source "drivers/pci/Kconfig" > > > > > > config HOTPLUG_CPU > > > bool "Support for hot-pluggable CPUs" > > > - depends on SMP && EXPERIMENTAL && PPC_PSERIES > > > + depends on SMP && EXPERIMENTAL && (PPC_PSERIES || > > PPC_PMAC) > > > select
[PATCH] thermal: clean up whitespace in scan code
From: Hugh Kang Signed-off-by: Hugh Kang --- drivers/thermal/thermal_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index d9e525c..115b959 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -506,7 +506,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, int *temp) if (!ret && *temp < crit_temp) *temp = tz->emul_temperature; } - + mutex_unlock(>lock); exit: return ret; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] crypto: KEYS: convert public key to the akcipher api
On Tue, Dec 22, 2015 at 06:23:59AM -0800, Tadeusz Struk wrote: > > What about the first two. This one is completely unrelated. > It only supposed to fix some random configuration issue > reported by a build robot, which isn't really important now. > The other two convert the module verifier to the new API. No this compile breakage was introduced by your first two patches because you changed crypto/public_key.h which is used by entities outside of your patch. So fix your first two patches by not breaking existing users of it. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 68/77] ncr5380: Fix whitespace issues using regexp
On Tue, 22 Dec 2015, James Bottomley wrote:
> I don't think it is trivial. I can't actually find a single instance in
> this patch where collapsing the space at the start of the comment looks
> justified; most of the time it eliminates intended formatting.
The present formatting is broken. It differs between the two core driver
forks. One uses spaces, the other tabs. For example, line 3.
$ grep -c "^ [*] *\t" drivers/scsi/{atari_,}NCR5380.c
drivers/scsi/atari_NCR5380.c:14
drivers/scsi/NCR5380.c:23
This patch resolves the issue by deliberately adopting an easy and
foolproof formatting convention.
But clearly there are different views as to what convention should be used
here. It would be great if you would indicate an acceptable convention so
we don't have to bikeshed the use of whitespace in comments.
To set an example, would you be kind enough to reformat, say, the comment
block at the top of the two files? Or some other comment where kernel-doc
is not appropriate, and the comment isn't merely duplicating actual code?
Thanks.
> Even if there's an odd one I've missed where space at the beginning of a
> comment is a problem, I think not doing that part of the regexp and just
> correcting the odd missed case by hand later will be much better.
>
> James
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 68/77] ncr5380: Fix whitespace issues using regexp
On Wed, 2015-12-23 at 13:03 +1100, Finn Thain wrote: > On Tue, 22 Dec 2015, Joe Perches wrote: > > > On Wed, 2015-12-23 at 11:56 +1100, Finn Thain wrote: > > > On Tue, 22 Dec 2015, Joe Perches wrote: > > > > > > > On Tue, 2015-12-22 at 12:18 +1100, Finn Thain wrote: > > > > > This patch is just the result of two substitutions. The first > > > > > removes any tabs and spaces at the end of the line. The second > > > > > replaces runs of tabs and spaces at the beginning of comment lines > > > > > with a single space. > > > > > > > > I think the second of these isn't done well. > > > > > > The aim of this patch is not to fix code style, but to make it > > > possible to compare these two files so that the fork can be repaired. > > > Regexp is very helpful in creating uniformity (and a minimal diff). > > > > > > If this was a coding style issue, we would be discussing the use of > > > kernel-doc format for the affected comments, not whitespace. > > > > > > > Many of these comments post reformatting are much worse to read > > > > because of lost alignment. > > > > > > You exaggerate a very trivial point. > > > > > > > > I prefer that all patches be improvements. > > > > Agreed. But the example you cited is an improvement, in that it creates > consistency. I think "consistency" isn't a useful argument. The kernel code doesn't care about any other external code bases. > Like you, I prefer to see formal parameters aligned when wrapped. But this > isn't a formal parameter list, it is a comment, and no comment should > duplicate code. > > Can you suggest a better regexp? Since this is patch 68 in the series, > there is a good chance that it will need to be regenerated. I suggest you do 2 patches here. One that removes unnecessary trailing spaces and converts multiple leading spaces to tabs where appropriate and a second patch that fixes whatever odd indentation that does exist after comment leading *. I think there aren't many instances of those and I think those should be done by hand rather than regex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5] extcon: add Maxim MAX3355 driver
On 2015년 12월 22일 20:15, Sergei Shtylyov wrote: > Hello. > > On 12/22/2015 4:13 AM, Chanwoo Choi wrote: > >> This patch depend on GPIOLIB configuration as following: >> I modified it with following diff and applied it. >> >> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig >> index ba4db7d..3d89e60 100644 >> --- a/drivers/extcon/Kconfig >> +++ b/drivers/extcon/Kconfig >> @@ -54,6 +54,7 @@ config EXTCON_MAX14577 >> >> config EXTCON_MAX3355 >>tristate "Maxim MAX3355 USB OTG EXTCON Support" >> + depends on GPIOLIB || COMPILE_TEST > > If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST? > And no, it shouldn't depend on gpiolib. It has empty stubs for the > case of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO > headers, I'll look into it. Yes. When GPIOLIB is disabled, the build issue don't happen. >>> >>> What? It surely does happen! >> >> hmm >> Sure. you need to check the include/linux/gpio/consumer.h. >> >> Because of build error happen, you miss to include the >> "linux/gpio/consumer.h" >> header file in extcon-max3355.c. Please test it for enough time. > >Yes, with this file #include'd, it build fine now. > because include/linux/gpio/consumer.h implement the dummy function for all gpio functions if CONFIG_GPIOLIB is disabled. >>> >>> Linus W. advised to #include this header explicitly -- I'll try and >>> post. >> >> Don't necessary. I already updated it including the >> "include/linux/gpio/consumer.h". > >I saw that, yes. > For correct operation of max3355, you should add the dependency to the extcon-max3355.c driver. This driver use the GPIO library certainly. >>> >>> I disagree. The driver will just cease to load in this case. I don't >>> see why we need such dependency. Only compilation time dependencies should >>> be >>> specified, I think. >> >> This driver have to depend on GPIOLIB. >> Why are you disagreeing the COMPILE_TEST dependency? It is just compile test >> without anything. > >I agree now. I still disagree about the gpiolib dependency though. If gpiolib is disabled, extcon-max3355.c might not operate it correctly. Just this driver could be built without operation because gpiolib function will not do the any behavior. I think that it is not too much problem. I should send the pull request within this week. If you want to need more discussion of extcon-max3355.c, I will not include it on pull request for v4.5 because there is issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3 RESEND] USB: serial: cp210x: New 16-bit register access functions.
cp210x_get_config and cp210x_set_config are cumbersome to use. This change
introduces new register access functions for 16-bit values, instead of
the above functions.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 155 +++-
1 file changed, 111 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index fd67958..fd7c4f4 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -422,14 +422,88 @@ static int cp210x_set_config(struct usb_serial_port
*port, u8 request,
}
/*
- * cp210x_set_config_single
- * Convenience function for calling cp210x_set_config on single data values
- * without requiring an integer pointer
+ * Reads a variable-sized block of CP210X_ registers, identified by req.
+ * Returns data into buf in native USB byte order.
*/
-static inline int cp210x_set_config_single(struct usb_serial_port *port,
- u8 request, unsigned int data)
+static int cp210x_read_reg_block(struct usb_serial_port *port, u8 req,
+ void *buf, int bufsize)
{
- return cp210x_set_config(port, request, , 2);
+ struct usb_serial *serial = port->serial;
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ void *dmabuf;
+ int result;
+
+ dmabuf = kmalloc(bufsize, GFP_KERNEL);
+ if (!dmabuf) {
+ /*
+* FIXME Some callers don't bother to check for error,
+* at least give them consistent junk until they are fixed
+*/
+ memset(buf, 0, bufsize);
+ return -ENOMEM;
+ }
+
+ result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
+ req, REQTYPE_INTERFACE_TO_HOST, 0,
+ port_priv->bInterfaceNumber, dmabuf, bufsize,
+ USB_CTRL_SET_TIMEOUT);
+ if (result == bufsize) {
+ memcpy(buf, dmabuf, bufsize);
+ result = 0;
+ } else {
+ dev_err(>dev, "failed get req 0x%x size %d status: %d\n",
+ req, bufsize, result);
+ if (result >= 0)
+ result = -EPROTO;
+
+ /*
+* FIXME Some callers don't bother to check for error,
+* at least give them consistent junk until they are fixed
+*/
+ memset(buf, 0, bufsize);
+ }
+
+ kfree(dmabuf);
+
+ return result;
+}
+
+/*
+ * Reads any 16-bit CP210X_ register identified by req.
+ */
+static int cp210x_read_u16_reg(struct usb_serial_port *port, u8 req, u16 *val)
+{
+ __le16 le16_val;
+ int err;
+
+ err = cp210x_read_reg_block(port, req, _val, sizeof(le16_val));
+ if (err)
+ return err;
+
+ *val = le16_to_cpu(le16_val);
+ return 0;
+}
+
+/*
+ * Writes any 16-bit CP210X_ register (req) whose value is passed
+ * entirely in the wValue field of the USB request.
+ */
+static int cp210x_write_u16_reg(struct usb_serial_port *port, u8 req, u16 val)
+{
+ struct usb_serial *serial = port->serial;
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ int result;
+
+ result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
+ req, REQTYPE_HOST_TO_INTERFACE, val,
+ port_priv->bInterfaceNumber, NULL, 0,
+ USB_CTRL_SET_TIMEOUT);
+ if (result < 0) {
+ dev_err(>dev, "failed set request 0x%x status: %d\n",
+ req, result);
+ }
+
+ return result;
}
/*
@@ -441,48 +515,47 @@ static inline int cp210x_set_config_single(struct
usb_serial_port *port,
static int cp210x_detect_swapped_line_ctl(struct usb_serial_port *port)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
- unsigned int line_ctl_save;
- unsigned int line_ctl_test;
+ u16 line_ctl_save;
+ u16 line_ctl_test;
int err;
- err = cp210x_get_config(port, CP210X_GET_LINE_CTL, _ctl_save, 2);
+ err = cp210x_read_u16_reg(port, CP210X_GET_LINE_CTL, _ctl_save);
if (err)
return err;
- line_ctl_test = 0x800;
- err = cp210x_set_config(port, CP210X_SET_LINE_CTL, _ctl_test, 2);
+ err = cp210x_write_u16_reg(port, CP210X_SET_LINE_CTL, 0x800);
if (err)
return err;
- err = cp210x_get_config(port, CP210X_GET_LINE_CTL, _ctl_test, 2);
+ err = cp210x_read_u16_reg(port, CP210X_GET_LINE_CTL, _ctl_test);
if (err)
return err;
/* has_swapped_line_ctl is 0 here because port_priv was kzalloced */
if (line_ctl_test == 8) {
port_priv->has_swapped_line_ctl = true;
- line_ctl_save = swab16((u16)line_ctl_save);
+
[PATCH v2 2/3 RESEND] USB: serial: cp210x: New 8-bit and 32-bit register access functions.
cp210x_get_config and cp210x_set_config are cumbersome to use. This change
introduces new register access functions for 8 and 32-bit values, instead
of the above functions.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 92 ++---
1 file changed, 86 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index fd7c4f4..0c2273d 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -469,6 +469,29 @@ static int cp210x_read_reg_block(struct usb_serial_port
*port, u8 req,
}
/*
+ * Reads any 32-bit CP210X_ register identified by req.
+ */
+static int cp210x_read_u32_reg(struct usb_serial_port *port, u8 req, u32 *val)
+{
+ __le32 le32_val;
+ int err;
+
+ err = cp210x_read_reg_block(port, req, _val, sizeof(le32_val));
+ if (err) {
+ /*
+* FIXME Some callers don't bother to check for error,
+* at least give them consistent junk until they are fixed
+*/
+ *val = 0;
+ return err;
+ }
+
+ *val = le32_to_cpu(le32_val);
+
+ return 0;
+}
+
+/*
* Reads any 16-bit CP210X_ register identified by req.
*/
static int cp210x_read_u16_reg(struct usb_serial_port *port, u8 req, u16 *val)
@@ -481,10 +504,19 @@ static int cp210x_read_u16_reg(struct usb_serial_port
*port, u8 req, u16 *val)
return err;
*val = le16_to_cpu(le16_val);
+
return 0;
}
/*
+ * Reads any 8-bit CP210X_ register identified by req.
+ */
+static int cp210x_read_u8_reg(struct usb_serial_port *port, u8 req, u8 *val)
+{
+ return cp210x_read_reg_block(port, req, val, sizeof(*val));
+}
+
+/*
* Writes any 16-bit CP210X_ register (req) whose value is passed
* entirely in the wValue field of the USB request.
*/
@@ -507,6 +539,55 @@ static int cp210x_write_u16_reg(struct usb_serial_port
*port, u8 req, u16 val)
}
/*
+ * Writes a variable-sized block of CP210X_ registers, identified by req.
+ * Data in buf must be in native USB byte order.
+ */
+static int cp210x_write_reg_block(struct usb_serial_port *port, u8 req,
+ void *buf, int bufsize)
+{
+ struct usb_serial *serial = port->serial;
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ void *dmabuf;
+ int result;
+
+ dmabuf = kmalloc(bufsize, GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ memcpy(dmabuf, buf, bufsize);
+
+ result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
+ req, REQTYPE_HOST_TO_INTERFACE, 0,
+ port_priv->bInterfaceNumber, dmabuf, bufsize,
+ USB_CTRL_SET_TIMEOUT);
+
+ kfree(dmabuf);
+
+ if (result == bufsize) {
+ result = 0;
+ } else {
+ dev_err(>dev, "failed set req 0x%x size %d status: %d\n",
+ req, bufsize, result);
+ if (result >= 0)
+ result = -EPROTO;
+ }
+
+ return result;
+}
+
+/*
+ * Writes any 32-bit CP210X_ register identified by req.
+ */
+static int cp210x_write_u32_reg(struct usb_serial_port *port, u8 req, u32 val)
+{
+ __le32 le32_val;
+
+ le32_val = cpu_to_le32(val);
+
+ return cp210x_write_reg_block(port, req, _val, sizeof(le32_val));
+}
+
+/*
* Detect CP2108 GET_LINE_CTL bug and activate workaround.
* Write a known good value 0x800, read it back.
* If it comes back swapped the bug is detected.
@@ -706,10 +787,10 @@ static void cp210x_get_termios_port(struct
usb_serial_port *port,
{
struct device *dev = >dev;
unsigned int cflag, modem_ctl[4];
- unsigned int baud;
+ u32 baud;
u16 bits;
- cp210x_get_config(port, CP210X_GET_BAUDRATE, , 4);
+ cp210x_read_u32_reg(port, CP210X_GET_BAUDRATE, );
dev_dbg(dev, "%s - baud rate = %d\n", __func__, baud);
*baudp = baud;
@@ -856,8 +937,7 @@ static void cp210x_change_speed(struct tty_struct *tty,
baud = cp210x_quantise_baudrate(baud);
dev_dbg(>dev, "%s - setting baud rate to %u\n", __func__, baud);
- if (cp210x_set_config(port, CP210X_SET_BAUDRATE, ,
- sizeof(baud))) {
+ if (cp210x_write_u32_reg(port, CP210X_SET_BAUDRATE, baud)) {
dev_warn(>dev, "failed to set baud rate to %u\n", baud);
if (old_termios)
baud = old_termios->c_ospeed;
@@ -1028,10 +1108,10 @@ static void cp210x_dtr_rts(struct usb_serial_port *p,
int on)
static int cp210x_tiocmget(struct tty_struct *tty)
{
struct usb_serial_port *port = tty->driver_data;
- unsigned int control;
+ u8 control;
int result;
- cp210x_get_config(port, CP210X_GET_MDMSTS, , 1);
+ cp210x_read_u8_reg(port,
[PATCH v2 3/3 RESEND] USB: serial: cp210x: New register access functions for large registers
cp210x_get_config and cp210x_set_config are cumbersome to use. This change
switches large register access to use new block functions. The old
functions are removed because now they become unused.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 137
1 file changed, 24 insertions(+), 113 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 0c2273d..ce80d5f 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -323,105 +323,6 @@ struct cp210x_comm_status {
#define PURGE_ALL 0x000f
/*
- * cp210x_get_config
- * Reads from the CP210x configuration registers
- * 'size' is specified in bytes.
- * 'data' is a pointer to a pre-allocated array of integers large
- * enough to hold 'size' bytes (with 4 bytes to each integer)
- */
-static int cp210x_get_config(struct usb_serial_port *port, u8 request,
- unsigned int *data, int size)
-{
- struct usb_serial *serial = port->serial;
- struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
- __le32 *buf;
- int result, i, length;
-
- /* Number of integers required to contain the array */
- length = (((size - 1) | 3) + 1) / 4;
-
- buf = kcalloc(length, sizeof(__le32), GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
- /* Issue the request, attempting to read 'size' bytes */
- result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
- request, REQTYPE_INTERFACE_TO_HOST, 0x,
- port_priv->bInterfaceNumber, buf, size,
- USB_CTRL_GET_TIMEOUT);
-
- /* Convert data into an array of integers */
- for (i = 0; i < length; i++)
- data[i] = le32_to_cpu(buf[i]);
-
- kfree(buf);
-
- if (result != size) {
- dev_dbg(>dev, "%s - Unable to send config request,
request=0x%x size=%d result=%d\n",
- __func__, request, size, result);
- if (result > 0)
- result = -EPROTO;
-
- return result;
- }
-
- return 0;
-}
-
-/*
- * cp210x_set_config
- * Writes to the CP210x configuration registers
- * Values less than 16 bits wide are sent directly
- * 'size' is specified in bytes.
- */
-static int cp210x_set_config(struct usb_serial_port *port, u8 request,
- unsigned int *data, int size)
-{
- struct usb_serial *serial = port->serial;
- struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
- __le32 *buf;
- int result, i, length;
-
- /* Number of integers required to contain the array */
- length = (((size - 1) | 3) + 1) / 4;
-
- buf = kmalloc(length * sizeof(__le32), GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
- /* Array of integers into bytes */
- for (i = 0; i < length; i++)
- buf[i] = cpu_to_le32(data[i]);
-
- if (size > 2) {
- result = usb_control_msg(serial->dev,
- usb_sndctrlpipe(serial->dev, 0),
- request, REQTYPE_HOST_TO_INTERFACE, 0x,
- port_priv->bInterfaceNumber, buf, size,
- USB_CTRL_SET_TIMEOUT);
- } else {
- result = usb_control_msg(serial->dev,
- usb_sndctrlpipe(serial->dev, 0),
- request, REQTYPE_HOST_TO_INTERFACE, data[0],
- port_priv->bInterfaceNumber, NULL, 0,
- USB_CTRL_SET_TIMEOUT);
- }
-
- kfree(buf);
-
- if ((size > 2 && result != size) || result < 0) {
- dev_dbg(>dev, "%s - Unable to send request, request=0x%x
size=%d result=%d\n",
- __func__, request, size, result);
- if (result > 0)
- result = -EPROTO;
-
- return result;
- }
-
- return 0;
-}
-
-/*
* Reads a variable-sized block of CP210X_ registers, identified by req.
* Returns data into buf in native USB byte order.
*/
@@ -786,7 +687,8 @@ static void cp210x_get_termios_port(struct usb_serial_port
*port,
unsigned int *cflagp, unsigned int *baudp)
{
struct device *dev = >dev;
- unsigned int cflag, modem_ctl[4];
+ unsigned int cflag;
+ u8 modem_ctl[16];
u32 baud;
u16 bits;
@@ -884,8 +786,9 @@ static void cp210x_get_termios_port(struct usb_serial_port
*port,
break;
}
- cp210x_get_config(port, CP210X_GET_FLOW, modem_ctl, 16);
- if (modem_ctl[0] & 0x0008) {
+ cp210x_read_reg_block(port, CP210X_GET_FLOW, modem_ctl,
+ sizeof(modem_ctl));
+ if (modem_ctl[0] & 8) {
dev_dbg(dev, "%s - flow control =
RE: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts
> -Original Message-
> From: rkrc...@redhat.com [mailto:rkrc...@redhat.com]
> Sent: Wednesday, December 23, 2015 3:53 AM
> To: Wu, Feng
> Cc: Yang Zhang ; pbonz...@redhat.com;
> k...@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu
> (jiang@linux.intel.com)
> Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-
> priority interrupts
>
> 2015-12-22 07:19+, Wu, Feng:
> >> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
> >> On 2015/12/22 14:59, Wu, Feng wrote:
> >> >> From: Yang Zhang [mailto:yang.zhang...@gmail.com]
> >> >> On 2015/12/16 9:37, Feng Wu wrote:
> >> >>> + for_each_set_bit(i, , 16) {
> >> >>> + if (!dst[i]
> >> >> && !kvm_lapic_enabled(dst[i]->vcpu)) {
> >> >>
> >> >> It should be or(||) not and (&&).
> >> >
> >> > Oh, you are right! My negligence! Thanks for pointing this out, Yang!
> >>
> >> btw, i think the kvm_lapic_enabled check is wrong here? Why need it
> here?
> >> >>>
> >> >>> If the lapic is not enabled, I think we cannot recognize it as a
> >> >>> candidate,
> can
> >> >> we?
> >> >>> Maybe Radim can confirm this, Radim, what is your option?
>
> SDM 10.6.2.2 Logical Destination Mode:
> For both configurations of logical destination mode, when combined
> with lowest priority delivery mode, software is responsible for
> ensuring that all of the local APICs included in or addressed by the
> IPI or I/O subsystem interrupt are present and enabled to receive the
> interrupt.
>
Radim, thanks a lot for your feedback!
> The case is undefined if some targeted LAPICs weren't hardware enabled
> as no interrupts can be delivered to hardware disabled LAPIC, so we can
> check for hardware enabled.
>
> It's not obvious if "enabled to receive the interrupt" means hardware or
> software enabled, but lowest priority cannot deliver NMI/INIT/..., so
> checking for software enabled doesn't restrict any valid uses either.
>
> so ... KVM only musn't blow up when encountering this situation :)
>
> The current code seems correct, but redundant. Just for reference, KVM
> now does:
> - check for software enabled LAPIC since patch aefd18f01ee8 ("KVM: x86:
> In DM_LOWEST, only deliver interrupts to vcpus with enabled LAPIC's")
> - check only for hardware enabled LAPIC in the fast path, since
> 1e08ec4a130e ("KVM: optimize apic interrupt delivery"))
Software enabled LAPIC is also checked in patch 1e08ec4a130e
("KVM: optimize apic interrupt delivery"), however, it was removed
in patch 3b5a5ffa928a3f875b0d5dd284eeb7c322e1688a. Now I am
a little confused about the policy, when and where should we do
the software/hardware enabled check?
>
> (v1 was arguable better, I pointed the need for enabled LAPIC in v1 only
> from looking at one KVM function, sorry.)
>
> >> >> Lapic can be disable by hw or sw. Here we only need to check the hw is
> >> >> enough which is already covered while injecting the interrupt into
> >> >> guest. I remember we(Glab, Macelo and me) have discussed it several ago,
> >> >> but i cannot find the mail thread.
> >>
> >> >
> >> > But if the lapic is disabled by software, we cannot still inject
> >> > interrupts to
> >> > it, can we?
> >>
> >> Yes, We cannot inject the normal interrupt. But this already covered by
> >> current logic and add a check here seems meaningless. Conversely, it may
> >> do bad thing..
> >>
> >
> > Let's wait for Radim/Paolo's opinions about this.
>
> I'd pick whatever results in less code: this time it seems like checking
> for hardware enabled LAPIC in both paths (implicitly in the fast path).
> Maybe it can be done better, I haven't given it much thought.
>
> We should revert aefd18f01ee8 at the same time, so our PI/non-PI slow
> paths won't diverge -- I hope it wasn't fixing a bug :)
>From the change log, It seems to me this patch was fixing a bug.
Thanks,
Feng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 68/77] ncr5380: Fix whitespace issues using regexp
On Tue, 22 Dec 2015, Joe Perches wrote: > On Wed, 2015-12-23 at 11:56 +1100, Finn Thain wrote: > > On Tue, 22 Dec 2015, Joe Perches wrote: > > > > > On Tue, 2015-12-22 at 12:18 +1100, Finn Thain wrote: > > > > This patch is just the result of two substitutions. The first > > > > removes any tabs and spaces at the end of the line. The second > > > > replaces runs of tabs and spaces at the beginning of comment lines > > > > with a single space. > > > > > > I think the second of these isn't done well. > > > > The aim of this patch is not to fix code style, but to make it > > possible to compare these two files so that the fork can be repaired. > > Regexp is very helpful in creating uniformity (and a minimal diff). > > > > If this was a coding style issue, we would be discussing the use of > > kernel-doc format for the affected comments, not whitespace. > > > > > Many of these comments post reformatting are much worse to read > > > because of lost alignment. > > > > You exaggerate a very trivial point. > > > > I prefer that all patches be improvements. > Agreed. But the example you cited is an improvement, in that it creates consistency. Like you, I prefer to see formal parameters aligned when wrapped. But this isn't a formal parameter list, it is a comment, and no comment should duplicate code. Can you suggest a better regexp? Since this is patch 68 in the series, there is a good chance that it will need to be regenerated. > > I admit that a small proportion of comments are slightly less > > readable. But it is the diff that needs to be readable in order to > > resolve the fork. > > diff -w works well. > Yes, it works well at times. For this I prefer to use meld. It does have text filters that allow the user to elide differences that match a given regexp. But I don't want every meld user to have to write those regexps. --
Re: [PATCH 1/7] printk: Hand over printing to console if printing too long
Hi,
slowly looking through the patches.
On (12/22/15 14:47), Jan Kara wrote:
[..]
> @@ -1803,10 +1869,24 @@ asmlinkage int vprintk_emit(int facility, int level,
> logbuf_cpu = UINT_MAX;
> raw_spin_unlock(_lock);
> lockdep_on();
> + /*
> + * By default we print message to console asynchronously so that kernel
> + * doesn't get stalled due to slow serial console. That can lead to
> + * softlockups, lost interrupts, or userspace timing out under heavy
> + * printing load.
> + *
> + * However we resort to synchronous printing of messages during early
> + * boot, when oops is in progress, or when synchronous printing was
> + * explicitely requested by kernel parameter.
> + */
> + if (keventd_up() && !oops_in_progress && !sync_print) {
> + __this_cpu_or(printk_pending, PRINTK_PENDING_OUTPUT);
> + irq_work_queue(this_cpu_ptr(_up_klogd_work));
> + } else
> + sync_print = true;
> local_irq_restore(flags);
can we replace this oops_in_progress check with something more reliable?
CPU0CPU1 - CPUN
panic()
local_irq_disable()executing foo() with irqs disabled,
console_verbose() or processing an extremely long irq handler.
bust_spinlocks()
oops_in_progress++
smp_send_stop()
bust_spinlocks()
oops_in_progress-- ok, IPI arrives
dump_stack()/printk()/etc from IPI_CPU_STOP
"while (1) cpu_relax()" with irq/fiq
disabled/halt/etc.
smp_send_stop() wrapped in `oops_in_progress++/oops_in_progress--' is arch
specific,
and some platforms don't do any IPI-delivered (e.g. via num_online_cpus())
checks at
all. Some do. For example, arm/arm64:
void smp_send_stop(void)
...
/* Wait up to one second for other CPUs to stop */
timeout = USEC_PER_SEC;
while (num_online_cpus() > 1 && timeout--)
udelay(1);
if (num_online_cpus() > 1)
pr_warn("SMP: failed to stop secondary CPUs\n");
...
so there are non-zero chances that IPI will arrive to CPU after
'oops_in_progress--',
and thus dump_stack()/etc. happening on that/those cpu/cpus will be lost.
bust_spinlocks(0) does
...
if (--oops_in_progress == 0)
wake_up_klogd();
...
but local cpu has irqs disabled and `panic_timeout' can be zero.
How about setting 'sync_print' to 'true' in...
bust_spinlocks() /* only set to true */
or
console_verbose() /* um... may be... */
or
having a separate one-liner for that
void console_panic_mode(void)
{
sync_print = true;
}
and call it early in panic(), before we send out IPI_STOP.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] Improve drm_of_component_probe() and move rockchip to use it
On 23 December 2015 at 03:38, Liviu Dudau wrote: > On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote: >> Hello, >> >> This is v2 of the patchset trying to make drm_of_component_probe() cope with >> finding >> both local crtc ports and remote encoder ones. Heiko Stübner was nice enough >> to test >> an earlier version that was patched following Russell's suggestions on >> rk3288, but >> I haven't seen any reports from iMX or Armada users. >> >> Changelog: >> v2: Updated the drm_of_component_probe() comment to explain why the >> reference count >> is not dropped. Fixed the compare_port() function for rockchip as >> described by >> Russell. >> v1: Original submission. >> http://lists.freedesktop.org/archives/dri-devel/2015-November/094546.html > > Gentle ping, this has now been tested by Rockchip people and fixes the > earlier version > that had to be reverted in mainline. Can it be included in the -next > somewhere? It would be good to get Russell ack on the first one, especially after reading the previous thread. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] File system corruption with 4.4-rc3 and beyond
On Tue, 22 Dec 2015 16:17:25 -0800 Linus Torvalds wrote: > We *just* fixed this. It was pretty subtle, and the debugging went on > for several days. But the fixed got applied to the block tree earlier > today, and I just pulled it only 15 minutes ago and pushed it out just > now. Just my luck. I've spent probably 5 days or more on this thinking it was a hardware issue. :-/ > > So check current -git, it should work for you. > > (And if you care about the particular fix: it's commit 23688bf4f830: > "block: ensure to split after potentially bouncing a bio"). Thanks, I do care. I'll be backporting this commit to the kernel I test for my own code. > > And yes, the way to trigger it seems to be to run a 32-bit kernel and have > PAE. Yep, that's exactly the environment that I saw this in. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 68/77] ncr5380: Fix whitespace issues using regexp
On Wed, 2015-12-23 at 11:56 +1100, Finn Thain wrote: > On Tue, 22 Dec 2015, Joe Perches wrote: > > > On Tue, 2015-12-22 at 12:18 +1100, Finn Thain wrote: > > > This patch is just the result of two substitutions. The first > removes > > > any tabs and spaces at the end of the line. The second replaces > runs > > > of tabs and spaces at the beginning of comment lines with a > single > > > space. > > > > I think the second of these isn't done well. > > The aim of this patch is not to fix code style, but to make it > possible to compare these two files so that the fork can be repaired. > Regexp is very helpful in creating uniformity (and a minimal diff). > > If this was a coding style issue, we would be discussing the use of > kernel-doc format for the affected comments, not whitespace. > > > Many of these comments post reformatting are > > much worse to read because of lost alignment. > > You exaggerate a very trivial point. > > I admit that a small proportion of comments are slightly less > readable. But it is the diff that needs to be readable in order to > resolve the fork. > > As I said in patch 0, I am aware that this patch series can be > faulted on trivial grounds but in order to avoid churn I don't wish > to address those issues until the fork has been resolved. I don't think it is trivial. I can't actually find a single instance in this patch where collapsing the space at the start of the comment looks justified; most of the time it eliminates intended formatting. Even if there's an odd one I've missed where space at the beginning of a comment is a problem, I think not doing that part of the regexp and just correcting the odd missed case by hand later will be much better. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [BUG] File system corruption with 4.4-rc3 and beyond
On Tue, 22 Dec 2015 20:09:29 -0500 Steven Rostedt wrote: > On Tue, 22 Dec 2015 17:16:59 -0700 > Jens Axboe wrote: > > > I'm guessing it's the same issue that was recently diagnosed, which > > would make sense if you hit this on 32-bit with highmem. Patch is > > pending, if you feel inclined, it'd be great if you could add this patch > > and retry: > > > > http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=23688bf4f830a89866fd0ed3501e342a7360fe4f > > > > Linus says this is in his tree already. I just did a fresh pull, and > verified that it is. I'm kicking of my test now. > OK, it got passed the point where it usually starts spitting out the errors. I'm going to add this patch to my "fixes" patches that get added to my test kernels to fix issues that cause my tests to fail that were bugs outside my code ;-) This test takes over 8 hours (although the i386 portion is less than an hour). If it finishes with no problems other than my own, I'll let you know. Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] File system corruption with 4.4-rc3 and beyond
On Wed, Dec 23, 2015 at 8:16 AM, Jens Axboe wrote:
> On 12/22/2015 05:09 PM, Steven Rostedt wrote:
>>
>> OK, I started with 4.4-rc4 to add some urgent ftrace patches and
>> started testing. My tests started to fail, and then I noticed they
>> failed with v4.4-rc4 as well. I got strange errors. Finally, I noticed
>> that I was constantly getting messages like this:
>>
>> ata2.00: exception Emask 0x60 SAct 0x780 SErr 0x800 action 0x6 frozen
>> ata2.00: irq_stat 0x2000, host bus error
>> ata2: SError: { HostInt }
>> ata2.00: failed command: WRITE FPDMA QUEUED
>> ata2.00: cmd 61/00:b8:f3:f2:2e/08:00:0e:00:00/40 tag 23 ncq 1048576 out
>> res 40/00:d4:f3:0a:2f/00:00:0e:00:00/40 Emask 0x60 (host bus
>> error)
>> ata2.00: status: { DRDY }
>> ata2.00: failed command: WRITE FPDMA QUEUED
>> ata2.00: cmd 61/00:c0:f3:fa:2e/08:00:0e:00:00/40 tag 24 ncq 1048576 out
>> res 40/00:d4:f3:0a:2f/00:00:0e:00:00/40 Emask 0x60 (host bus
>> error)
>> ata2.00: status: { DRDY }
>> ata2.00: failed command: WRITE FPDMA QUEUED
>> ata2.00: cmd 61/00:c8:f3:02:2f/08:00:0e:00:00/40 tag 25 ncq 1048576 out
>> res 40/00:d4:f3:0a:2f/00:00:0e:00:00/40 Emask 0x60 (host bus
>> error)
>> ata2.00: status: { DRDY }
>> ata2.00: failed command: WRITE FPDMA QUEUED
>> ata2.00: cmd 61/b8:d0:f3:0a:2f/08:00:0e:00:00/40 tag 26 ncq 1142784 out
>> res 40/00:d4:f3:0a:2f/00:00:0e:00:00/40 Emask 0x60 (host bus
>> error)
>> ata2.00: status: { DRDY }
>> ata2: hard resetting link
>> ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
>> ata2.00: configured for UDMA/100
>> ata2: EH complete
>>
>>
>> The test box has a relatively new mobo and such, but I know the HD was
>> old. So I thought that the HD was simply failing. I installed a new HD
>> and spent lots of time since last Thursday trying to set it up to work
>> with my testing scripts. Unfortunately, I installed a newer Fedora that
>> no longer supported the older grub1 and I wasted lots of time trying to
>> get grub2 to do what I wanted. I finally gave up and used
>> syslinux/extlinux and got it working again. Unfortunately, I still got
>> these ata2 errors! I started thinking that the mobo may be bad.
>>
>> But then I decided to try an older kernel, and the errors never showed
>> up. I booted back and forth several times and the errors were very
>> reliable. I have multiple OSes on this box so every time I got an
>> error, I would boot into one of the other OSes and do fsck on the
>> filesystems. Because the longer I ran my tests with this bug, it would
>> eventually start corrupting the ext4 filesystem.
>>
>> Since it seemed very reliable, I started my bisect. It came down to this
>> patch:
>>
>> From 578270bfbd2803dc7b0b03fbc2ac119efbc73195 Mon Sep 17 00:00:00 2001
>> From: Ming Lei
>> Date: Tue, 24 Nov 2015 10:35:29 +0800
>> Subject: [PATCH] block: fix segment split
>>
>>
>> I thought this strange, because I don't see anything wrong with this
>> patch. But if I removed it, the problem went away, and when I added it
>> back, the problem would show up easily.
>>
>> I checkout v4.4-rc6 and tested again, thinking something else may be
>> wrong and has since been fixed. Nope, the error still showed up. I then
>> removed this commit and tried again. Sure enough, the problem went away!
>
>
> Probably the other way around, I think, it uncovered an issue with the
> segment counting for certain cases.
Diethard said the same case can be fixed by the patch 'block:
ensure to split after potentially bouncing a bio', so please just test it.
Also looks it is helpful to add a warning for the splitted bio in
bio_for_each_segment_all().
>
>> My guess is that there's another bug lurking around somewhere, and the
>> bug that this patch fixed hid the problem. Now that this patch fixed a
>> bug that would hide the issue, the issue is showing up.
>>
>> I'll pass this along to the block experts and see what you can think of
>> it. I attached my config, and the test was a script that stress
>> trace-cmd filters.
>>
>> Oh, and I ran this on my i386 kernel and OS. I haven't tried testing
>> much on x86_64 as my tests start with i386. It originally had issues in
>> x86_64 but that may be because the i386 test corrupted the filesystem
>> which is shared.
>>
>> There may be a 32bit vs 64bit issue somewhere?
>
>
> I'm guessing it's the same issue that was recently diagnosed, which would
> make sense if you hit this on 32-bit with highmem. Patch is pending, if you
> feel inclined, it'd be great if you could add this patch and retry:
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=23688bf4f830a89866fd0ed3501e342a7360fe4f
>
> --
> Jens Axboe
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 68/77] ncr5380: Fix whitespace issues using regexp
On Wed, 2015-12-23 at 11:56 +1100, Finn Thain wrote: > On Tue, 22 Dec 2015, Joe Perches wrote: > > > On Tue, 2015-12-22 at 12:18 +1100, Finn Thain wrote: > > > This patch is just the result of two substitutions. The first removes > > > any tabs and spaces at the end of the line. The second replaces runs > > > of tabs and spaces at the beginning of comment lines with a single > > > space. > > > > I think the second of these isn't done well. > > The aim of this patch is not to fix code style, but to make it possible to > compare these two files so that the fork can be repaired. Regexp is very > helpful in creating uniformity (and a minimal diff). > > If this was a coding style issue, we would be discussing the use of > kernel-doc format for the affected comments, not whitespace. > > > Many of these comments post reformatting are > > much worse to read because of lost alignment. > > You exaggerate a very trivial point. I prefer that all patches be improvements. > I admit that a small proportion of comments are slightly less readable. > But it is the diff that needs to be readable in order to resolve the fork. diff -w works well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [BUG] File system corruption with 4.4-rc3 and beyond
On Tue, 22 Dec 2015 17:16:59 -0700 Jens Axboe wrote: > I'm guessing it's the same issue that was recently diagnosed, which > would make sense if you hit this on 32-bit with highmem. Patch is > pending, if you feel inclined, it'd be great if you could add this patch > and retry: > > http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=23688bf4f830a89866fd0ed3501e342a7360fe4f > Linus says this is in his tree already. I just did a fresh pull, and verified that it is. I'm kicking of my test now. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] f2fs: avoid unnecessary f2fs_gc for dir operations
The f2fs_balance_fs doesn't need to cover f2fs_new_inode or f2fs_find_entry
works.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/namei.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 2c32110..8d2616f 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -128,8 +128,6 @@ static int f2fs_create(struct inode *dir, struct dentry
*dentry, umode_t mode,
nid_t ino = 0;
int err;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, mode);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -142,6 +140,8 @@ static int f2fs_create(struct inode *dir, struct dentry
*dentry, umode_t mode,
inode->i_mapping->a_ops = _dblock_aops;
ino = inode->i_ino;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
if (err)
@@ -288,12 +288,13 @@ static int f2fs_unlink(struct inode *dir, struct dentry
*dentry)
int err = -ENOENT;
trace_f2fs_unlink_enter(dir, dentry);
- f2fs_balance_fs(sbi);
de = f2fs_find_entry(dir, >d_name, );
if (!de)
goto fail;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = acquire_orphan_inode(sbi);
if (err) {
@@ -341,8 +342,6 @@ static int f2fs_symlink(struct inode *dir, struct dentry
*dentry,
if (len > dir->i_sb->s_blocksize)
return -ENAMETOOLONG;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, S_IFLNK | S_IRWXUGO);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -353,6 +352,8 @@ static int f2fs_symlink(struct inode *dir, struct dentry
*dentry,
inode->i_op = _symlink_inode_operations;
inode->i_mapping->a_ops = _dblock_aops;
+ f2fs_balance_fs(sbi);
+
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
if (err)
@@ -433,8 +434,6 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
struct inode *inode;
int err;
- f2fs_balance_fs(sbi);
-
inode = f2fs_new_inode(dir, S_IFDIR | mode);
if (IS_ERR(inode))
return PTR_ERR(inode);
@@ -444,6 +443,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
inode->i_mapping->a_ops = _dblock_aops;
mapping_set_gfp_mask(inode->i_mapping, GFP_F2FS_HIGH_ZERO);
+ f2fs_balance_fs(sbi);
+
set_inode_flag(F2FS_I(inode), FI_INC_LINK);
f2fs_lock_op(sbi);
err = f2fs_add_link(dentry, inode);
--
2.5.4 (Apple Git-61)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: call f2fs_balance_fs only when node was changed
If user tries to update or read data, we don't need to call f2fs_balance_fs
which triggers f2fs_gc, which increases unnecessary long latency.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 19 ---
fs/f2fs/file.c | 26 +-
fs/f2fs/inline.c | 4
3 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index a7a9a05..8f8f8b0 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -509,7 +509,6 @@ static void __allocate_data_blocks(struct inode *inode,
loff_t offset,
u64 end_offset;
while (len) {
- f2fs_balance_fs(sbi);
f2fs_lock_op(sbi);
/* When reading holes, we need its node page */
@@ -542,6 +541,9 @@ static void __allocate_data_blocks(struct inode *inode,
loff_t offset,
f2fs_put_dnode();
f2fs_unlock_op(sbi);
+
+ if (dn.node_changed)
+ f2fs_balance_fs(sbi);
}
return;
@@ -551,6 +553,8 @@ sync_out:
f2fs_put_dnode();
out:
f2fs_unlock_op(sbi);
+ if (dn.node_changed)
+ f2fs_balance_fs(sbi);
return;
}
@@ -1410,8 +1414,6 @@ static int f2fs_write_begin(struct file *file, struct
address_space *mapping,
trace_f2fs_write_begin(inode, pos, len, flags);
- f2fs_balance_fs(sbi);
-
/*
* We should check this at this moment to avoid deadlock on inode page
* and #0 page. The locking rule for inline_data conversion should be:
@@ -1461,6 +1463,17 @@ put_next:
f2fs_put_dnode();
f2fs_unlock_op(sbi);
+ if (dn.node_changed && has_not_enough_free_secs(sbi, 0)) {
+ unlock_page(page);
+ f2fs_balance_fs(sbi);
+ lock_page(page);
+ if (page->mapping != mapping) {
+ /* The page got truncated from under us */
+ f2fs_put_page(page, 1);
+ goto repeat;
+ }
+ }
+
f2fs_wait_on_page_writeback(page, DATA);
/* wait for GCed encrypted page writeback */
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 10ed357..dbc08bb 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -40,8 +40,6 @@ static int f2fs_vm_page_mkwrite(struct vm_area_struct *vma,
struct dnode_of_data dn;
int err;
- f2fs_balance_fs(sbi);
-
sb_start_pagefault(inode->i_sb);
f2fs_bug_on(sbi, f2fs_has_inline_data(inode));
@@ -57,6 +55,9 @@ static int f2fs_vm_page_mkwrite(struct vm_area_struct *vma,
f2fs_put_dnode();
f2fs_unlock_op(sbi);
+ if (dn.node_changed)
+ f2fs_balance_fs(sbi);
+
file_update_time(vma->vm_file);
lock_page(page);
if (unlikely(page->mapping != inode->i_mapping ||
@@ -233,9 +234,6 @@ int f2fs_sync_file(struct file *file, loff_t start, loff_t
end, int datasync)
goto out;
}
go_write:
- /* guarantee free sections for fsync */
- f2fs_balance_fs(sbi);
-
/*
* Both of fdatasync() and fsync() are able to be recovered from
* sudden-power-off.
@@ -267,6 +265,8 @@ sync_nodes:
if (need_inode_block_update(sbi, ino)) {
mark_inode_dirty_sync(inode);
f2fs_write_inode(inode, NULL);
+
+ f2fs_balance_fs(sbi);
goto sync_nodes;
}
@@ -946,8 +946,6 @@ static int f2fs_collapse_range(struct inode *inode, loff_t
offset, loff_t len)
if (offset & (F2FS_BLKSIZE - 1) || len & (F2FS_BLKSIZE - 1))
return -EINVAL;
- f2fs_balance_fs(F2FS_I_SB(inode));
-
ret = f2fs_convert_inline_inode(inode);
if (ret)
return ret;
@@ -994,8 +992,6 @@ static int f2fs_zero_range(struct inode *inode, loff_t
offset, loff_t len,
if (ret)
return ret;
- f2fs_balance_fs(sbi);
-
ret = f2fs_convert_inline_inode(inode);
if (ret)
return ret;
@@ -1105,12 +1101,12 @@ static int f2fs_insert_range(struct inode *inode,
loff_t offset, loff_t len)
if (offset & (F2FS_BLKSIZE - 1) || len & (F2FS_BLKSIZE - 1))
return -EINVAL;
- f2fs_balance_fs(sbi);
-
ret = f2fs_convert_inline_inode(inode);
if (ret)
return ret;
+ f2fs_balance_fs(sbi);
+
ret = truncate_blocks(inode, i_size_read(inode), true);
if (ret)
return ret;
@@ -1153,8 +1149,6 @@ static int expand_inode_data(struct inode *inode, loff_t
offset,
loff_t off_start, off_end;
int ret = 0;
- f2fs_balance_fs(sbi);
-
ret = inode_newsize_ok(inode, (len + offset));
if (ret)
return ret;
@@ -1163,6 +1157,8 @@ static int expand_inode_data(struct inode *inode, loff_t
offset,
if (ret)
return ret;
+ f2fs_balance_fs(sbi);
+
[PATCH 3/4] f2fs: record node block allocation in dnode_of_data
This patch introduces recording node block allocation in dnode_of_data.
This information helps to figure out whether any node block is allocated during
specific file operations.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 1 +
fs/f2fs/f2fs.h | 1 +
fs/f2fs/file.c | 1 +
fs/f2fs/node.c | 4
4 files changed, 7 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index cf0c9dd..a7a9a05 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -226,6 +226,7 @@ void set_data_blkaddr(struct dnode_of_data *dn)
addr_array = blkaddr_in_node(rn);
addr_array[ofs_in_node] = cpu_to_le32(dn->data_blkaddr);
set_page_dirty(node_page);
+ dn->node_changed = true;
}
int reserve_new_block(struct dnode_of_data *dn)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 90fb970..0f4d329 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -547,6 +547,7 @@ struct dnode_of_data {
unsigned int ofs_in_node; /* data offset in the node page */
bool inode_page_locked; /* inode page is locked or not */
block_t data_blkaddr; /* block address of the node block */
+ bool node_changed; /* is node block changed */
};
static inline void set_new_dnode(struct dnode_of_data *dn, struct inode *inode,
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f2effe1..10ed357 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -484,6 +484,7 @@ int truncate_data_blocks_range(struct dnode_of_data *dn,
int count)
dec_valid_block_count(sbi, dn->inode, nr_free);
set_page_dirty(dn->node_page);
sync_inode_page(dn);
+ dn->node_changed = true;
}
dn->ofs_in_node = ofs;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 6cc8ac7..ff2acb1 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -542,6 +542,7 @@ int get_dnode_of_data(struct dnode_of_data *dn, pgoff_t
index, int mode)
set_nid(parent, offset[i - 1], nids[i], i == 1);
alloc_nid_done(sbi, nids[i]);
+ dn->node_changed = true;
done = true;
} else if (mode == LOOKUP_NODE_RA && i == level && level > 1) {
npage[i] = get_node_page_ra(parent, offset[i - 1]);
@@ -678,6 +679,7 @@ static int truncate_nodes(struct dnode_of_data *dn,
unsigned int nofs,
if (ret < 0)
goto out_err;
set_nid(page, i, 0, false);
+ dn->node_changed = true;
}
} else {
child_nofs = nofs + ofs * (NIDS_PER_BLOCK + 1) + 1;
@@ -691,6 +693,7 @@ static int truncate_nodes(struct dnode_of_data *dn,
unsigned int nofs,
ret = truncate_nodes(, child_nofs, 0, depth - 1);
if (ret == (NIDS_PER_BLOCK + 1)) {
set_nid(page, i, 0, false);
+ dn->node_changed = true;
child_nofs += ret;
} else if (ret < 0 && ret != -ENOENT) {
goto out_err;
@@ -752,6 +755,7 @@ static int truncate_partial_nodes(struct dnode_of_data *dn,
if (err < 0)
goto fail;
set_nid(pages[idx], i, 0, false);
+ dn->node_changed = true;
}
if (offset[idx + 1] == 0) {
--
2.5.4 (Apple Git-61)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: check inline_data flag at converting time
We can check inode's inline_data flag when calling to convert it.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 8 +++-
fs/f2fs/file.c | 58 ++--
fs/f2fs/inline.c | 3 +++
3 files changed, 29 insertions(+), 40 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index e34b1bd..cf0c9dd 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1573,11 +1573,9 @@ static ssize_t f2fs_direct_IO(struct kiocb *iocb, struct
iov_iter *iter,
int err;
/* we don't need to use inline_data strictly */
- if (f2fs_has_inline_data(inode)) {
- err = f2fs_convert_inline_inode(inode);
- if (err)
- return err;
- }
+ err = f2fs_convert_inline_inode(inode);
+ if (err)
+ return err;
if (f2fs_encrypted_inode(inode) && S_ISREG(inode->i_mode))
return 0;
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 7f8ca47..f2effe1 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -418,19 +418,18 @@ static loff_t f2fs_llseek(struct file *file, loff_t
offset, int whence)
static int f2fs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
struct inode *inode = file_inode(file);
+ int err;
if (f2fs_encrypted_inode(inode)) {
- int err = f2fs_get_encryption_info(inode);
+ err = f2fs_get_encryption_info(inode);
if (err)
return 0;
}
/* we don't need to use inline_data strictly */
- if (f2fs_has_inline_data(inode)) {
- int err = f2fs_convert_inline_inode(inode);
- if (err)
- return err;
- }
+ err = f2fs_convert_inline_inode(inode);
+ if (err)
+ return err;
file_accessed(file);
vma->vm_ops = _file_vm_ops;
@@ -604,7 +603,7 @@ int f2fs_truncate(struct inode *inode, bool lock)
trace_f2fs_truncate(inode);
/* we should check inline_data size */
- if (f2fs_has_inline_data(inode) && !f2fs_may_inline_data(inode)) {
+ if (!f2fs_may_inline_data(inode)) {
err = f2fs_convert_inline_inode(inode);
if (err)
return err;
@@ -688,8 +687,7 @@ int f2fs_setattr(struct dentry *dentry, struct iattr *attr)
truncate_setsize(inode, attr->ia_size);
/* should convert inline inode here */
- if (f2fs_has_inline_data(inode) &&
- !f2fs_may_inline_data(inode)) {
+ if (!f2fs_may_inline_data(inode)) {
err = f2fs_convert_inline_inode(inode);
if (err)
return err;
@@ -786,13 +784,11 @@ static int punch_hole(struct inode *inode, loff_t offset,
loff_t len)
{
pgoff_t pg_start, pg_end;
loff_t off_start, off_end;
- int ret = 0;
+ int ret;
- if (f2fs_has_inline_data(inode)) {
- ret = f2fs_convert_inline_inode(inode);
- if (ret)
- return ret;
- }
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ return ret;
pg_start = ((unsigned long long) offset) >> PAGE_CACHE_SHIFT;
pg_end = ((unsigned long long) offset + len) >> PAGE_CACHE_SHIFT;
@@ -951,11 +947,9 @@ static int f2fs_collapse_range(struct inode *inode, loff_t
offset, loff_t len)
f2fs_balance_fs(F2FS_I_SB(inode));
- if (f2fs_has_inline_data(inode)) {
- ret = f2fs_convert_inline_inode(inode);
- if (ret)
- return ret;
- }
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ return ret;
pg_start = offset >> PAGE_CACHE_SHIFT;
pg_end = (offset + len) >> PAGE_CACHE_SHIFT;
@@ -1001,11 +995,9 @@ static int f2fs_zero_range(struct inode *inode, loff_t
offset, loff_t len,
f2fs_balance_fs(sbi);
- if (f2fs_has_inline_data(inode)) {
- ret = f2fs_convert_inline_inode(inode);
- if (ret)
- return ret;
- }
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ return ret;
ret = filemap_write_and_wait_range(mapping, offset, offset + len - 1);
if (ret)
@@ -1114,11 +1106,9 @@ static int f2fs_insert_range(struct inode *inode, loff_t
offset, loff_t len)
f2fs_balance_fs(sbi);
- if (f2fs_has_inline_data(inode)) {
- ret = f2fs_convert_inline_inode(inode);
- if (ret)
- return ret;
- }
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ return ret;
ret = truncate_blocks(inode, i_size_read(inode), true);
if (ret)
@@ -1168,11 +1158,9 @@
Re: [PATCH v3 68/77] ncr5380: Fix whitespace issues using regexp
On Tue, 22 Dec 2015, Joe Perches wrote: > On Tue, 2015-12-22 at 12:18 +1100, Finn Thain wrote: > > This patch is just the result of two substitutions. The first removes > > any tabs and spaces at the end of the line. The second replaces runs > > of tabs and spaces at the beginning of comment lines with a single > > space. > > I think the second of these isn't done well. The aim of this patch is not to fix code style, but to make it possible to compare these two files so that the fork can be repaired. Regexp is very helpful in creating uniformity (and a minimal diff). If this was a coding style issue, we would be discussing the use of kernel-doc format for the affected comments, not whitespace. > Many of these comments post reformatting are > much worse to read because of lost alignment. You exaggerate a very trivial point. I admit that a small proportion of comments are slightly less readable. But it is the diff that needs to be readable in order to resolve the fork. As I said in patch 0, I am aware that this patch series can be faulted on trivial grounds but in order to avoid churn I don't wish to address those issues until the fork has been resolved. Thanks for your review. > > For instance: > > > +/* > > * Function : int NCR5380_select(struct Scsi_Host *instance, > > - * struct scsi_cmnd *cmd) > > + * struct scsi_cmnd *cmd) > > * > > * Purpose : establishes I_T_L or I_T_L_Q nexus for new or existing > > command, > > - * including ARBITRATION, SELECTION, and initial message out for > > - * IDENTIFY and queue messages. > > + * including ARBITRATION, SELECTION, and initial message out for > > + * IDENTIFY and queue messages. > --
[PATCH v2 0/2] Change PAT to support mremap use-cases
This patch-set fixes two issues found in PAT when mremap() is used on a VM_PFNMAP range. Patch 1/2 fixes an issue for mremap() with MREMAP_FIXED, which moves a pfnmap from old vma to new vma. untrack_pfn_moved() is added to clear VM_PAT from old vma. Patch 2/2 fixes an issue for mremap() with a shrinking map size. The free_memtype() path is changed to support this mremap case in addition to the regular munmap case. Note, using mremap() with an expanded map size is not a valid case since VM_DONTEXPAND is set along with VM_PFNMAP. v2: - Add an explicit call in the mremap code which clears the PAT flag. (Thomas Gleixner) - Add comment to explain how memtype_rb_match() is used for shrinking case. (Thomas Gleixner) --- Toshi Kani (2): 1/2 x86/mm/pat: Add untrack_pfn_moved for mremap 2/2 x86/mm/pat: Change free_memtype() to support shrinking case --- arch/x86/mm/pat.c | 12 +- arch/x86/mm/pat_rbtree.c | 52 +++ include/asm-generic/pgtable.h | 10 - mm/mremap.c | 4 4 files changed, 67 insertions(+), 11 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 v2 2/2] x86/mm/pat: Change free_memtype() to support shrinking case
Using mremap() to shrink the map size of a VM_PFNMAP range causes
the following error message, and leaves the pfn range allocated.
x86/PAT: test:3493 freeing invalid memtype [mem 0x48320-0x4863f]
This is because rbt_memtype_erase(), called from free_memtype()
with spin_lock held, only supports to free a whole memtype node in
memtype_rbroot. Therefore, this patch changes rbt_memtype_erase()
to support a request that shrinks the size of a memtype node for
mremap().
memtype_rb_exact_match() is renamed to memtype_rb_match(), and
is enhanced to support EXACT_MATCH and END_MATH in @match_type.
Since the memtype_rbroot tree allows overlapping ranges,
rbt_memtype_erase() checks with EXACT_MATCH first, i.e. free
a whole node for the munmap case. If no such entry is found,
it then checks with END_MATCH, i.e. shrink the size of a node
from the end for the mremap case.
On the mremap case, rbt_memtype_erase() proceeds in two steps,
1) remove the node, and then 2) insert the updated node. This
allows proper update of augmented values, subtree_max_end, in
the tree.
Link: http://lkml.kernel.org/r/<1446072663.20657.150.ca...@hpe.com>
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Borislav Petkov
Signed-off-by: Toshi Kani
---
arch/x86/mm/pat.c|2 +-
arch/x86/mm/pat_rbtree.c | 52 ++
2 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 1aca073..031782e 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -586,7 +586,7 @@ int free_memtype(u64 start, u64 end)
entry = rbt_memtype_erase(start, end);
spin_unlock(_lock);
- if (!entry) {
+ if (IS_ERR(entry)) {
pr_info("x86/PAT: %s:%d freeing invalid memtype [mem
%#010Lx-%#010Lx]\n",
current->comm, current->pid, start, end - 1);
return -EINVAL;
diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index 6393108..2f77022 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -98,8 +98,13 @@ static struct memtype *memtype_rb_lowest_match(struct
rb_root *root,
return last_lower; /* Returns NULL if there is no overlap */
}
-static struct memtype *memtype_rb_exact_match(struct rb_root *root,
- u64 start, u64 end)
+enum {
+ MEMTYPE_EXACT_MATCH = 0,
+ MEMTYPE_END_MATCH = 1
+};
+
+static struct memtype *memtype_rb_match(struct rb_root *root,
+ u64 start, u64 end, int match_type)
{
struct memtype *match;
@@ -107,7 +112,12 @@ static struct memtype *memtype_rb_exact_match(struct
rb_root *root,
while (match != NULL && match->start < end) {
struct rb_node *node;
- if (match->start == start && match->end == end)
+ if ((match_type == MEMTYPE_EXACT_MATCH) &&
+ (match->start == start) && (match->end == end))
+ return match;
+
+ if ((match_type == MEMTYPE_END_MATCH) &&
+ (match->start < start) && (match->end == end))
return match;
node = rb_next(>rb);
@@ -117,7 +127,7 @@ static struct memtype *memtype_rb_exact_match(struct
rb_root *root,
match = NULL;
}
- return NULL; /* Returns NULL if there is no exact match */
+ return NULL; /* Returns NULL if there is no match */
}
static int memtype_rb_check_conflict(struct rb_root *root,
@@ -210,12 +220,36 @@ struct memtype *rbt_memtype_erase(u64 start, u64 end)
{
struct memtype *data;
- data = memtype_rb_exact_match(_rbroot, start, end);
- if (!data)
- goto out;
+ /*
+* Since the memtype_rbroot tree allows overlapping ranges,
+* rbt_memtype_erase() checks with EXACT_MATCH first, i.e. free
+* a whole node for the munmap case. If no such entry is found,
+* it then checks with END_MATCH, i.e. shrink the size of a node
+* from the end for the mremap case.
+*/
+ data = memtype_rb_match(_rbroot, start, end,
+ MEMTYPE_EXACT_MATCH);
+ if (!data) {
+ data = memtype_rb_match(_rbroot, start, end,
+ MEMTYPE_END_MATCH);
+ if (!data)
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (data->start == start) {
+ /* munmap: erase this node */
+ rb_erase_augmented(>rb, _rbroot,
+ _rb_augment_cb);
+ } else {
+ /* mremap: update the end value of this node */
+ rb_erase_augmented(>rb, _rbroot,
+ _rb_augment_cb);
+ data->end = start;
+ data->subtree_max_end = data->end;
+ memtype_rb_insert(_rbroot, data);
[PATCH v2 1/2] x86/mm/pat: Add untrack_pfn_moved for mremap
mremap() with MREMAP_FIXED on a VM_PFNMAP range causes the following
WARN_ON_ONCE() message in untrack_pfn().
WARNING: CPU: 1 PID: 3493 at arch/x86/mm/pat.c:985 untrack_pfn+0xbd/0xd0()
Call Trace:
[] dump_stack+0x45/0x57
[] warn_slowpath_common+0x86/0xc0
[] warn_slowpath_null+0x1a/0x20
[] untrack_pfn+0xbd/0xd0
[] unmap_single_vma+0x80e/0x860
[] unmap_vmas+0x55/0xb0
[] unmap_region+0xac/0x120
[] do_munmap+0x28a/0x460
[] move_vma+0x1b3/0x2e0
[] SyS_mremap+0x3b3/0x510
[] entry_SYSCALL_64_fastpath+0x12/0x71
MREMAP_FIXED moves a pfnmap from old vma to new vma. untrack_pfn() is
called with the old vma after its pfnmap page table has been removed,
which causes follow_phys() to fail. The new vma has a new pfnmap to
the same pfn & cache type with VM_PAT set. Therefore, we only need to
clear VM_PAT from the old vma in this case.
Add untrack_pfn_moved(), which clears VM_PAT from a given old vma.
move_vma() is changed to call this function with the old vma when
VM_PFNMAP is set. move_vma() then calls do_munmap(), and untrack_pfn()
is a no-op since VM_PAT is cleared.
Link: http://lkml.kernel.org/r/<1446072663.20657.150.ca...@hpe.com>
Reported-by: Stas Sergeev
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Borislav Petkov
Signed-off-by: Toshi Kani
---
arch/x86/mm/pat.c | 10 ++
include/asm-generic/pgtable.h | 10 +-
mm/mremap.c |4
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 188e3e0..1aca073 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -992,6 +992,16 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned long
pfn,
vma->vm_flags &= ~VM_PAT;
}
+/*
+ * untrack_pfn_moved is called, while mremapping a pfnmap for a new region,
+ * with the old vma after its pfnmap page table has been removed. The new
+ * vma has a new pfnmap to the same pfn & cache type with VM_PAT set.
+ */
+void untrack_pfn_moved(struct vm_area_struct *vma)
+{
+ vma->vm_flags &= ~VM_PAT;
+}
+
pgprot_t pgprot_writecombine(pgprot_t prot)
{
return __pgprot(pgprot_val(prot) |
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 14b0ff32..3a6803c 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -569,7 +569,7 @@ static inline int track_pfn_copy(struct vm_area_struct *vma)
}
/*
- * untrack_pfn_vma is called while unmapping a pfnmap for a region.
+ * untrack_pfn is called while unmapping a pfnmap for a region.
* untrack can be called for a specific region indicated by pfn and size or
* can be for the entire vma (in which case pfn, size are zero).
*/
@@ -577,6 +577,13 @@ static inline void untrack_pfn(struct vm_area_struct *vma,
unsigned long pfn, unsigned long size)
{
}
+
+/*
+ * untrack_pfn_moved is called while mremapping a pfnmap for a new region.
+ */
+static inline void untrack_pfn_moved(struct vm_area_struct *vma)
+{
+}
#else
extern int track_pfn_remap(struct vm_area_struct *vma, pgprot_t *prot,
unsigned long pfn, unsigned long addr,
@@ -586,6 +593,7 @@ extern int track_pfn_insert(struct vm_area_struct *vma,
pgprot_t *prot,
extern int track_pfn_copy(struct vm_area_struct *vma);
extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
unsigned long size);
+extern void untrack_pfn_moved(struct vm_area_struct *vma);
#endif
#ifdef __HAVE_COLOR_ZERO_PAGE
diff --git a/mm/mremap.c b/mm/mremap.c
index c25bc62..de824e7 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -319,6 +319,10 @@ static unsigned long move_vma(struct vm_area_struct *vma,
hiwater_vm = mm->hiwater_vm;
vm_stat_account(mm, vma->vm_flags, vma->vm_file, new_len>>PAGE_SHIFT);
+ /* Tell pfnmap has moved from this vma */
+ if (unlikely(vma->vm_flags & VM_PFNMAP))
+ untrack_pfn_moved(vma);
+
if (do_munmap(mm, old_addr, old_len) < 0) {
/* OOM: unable to split vma, just get accounts right */
vm_unacct_memory(excess >> PAGE_SHIFT);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] iio:adc:at91_adc8xx: introduce new atmel adc driver
On Mon, Dec 21, 2015 at 10:24:08AM +0100, Ludovic Desroches wrote: > This driver supports the new version of the Atmel ADC device introduced > with the SAMA5D2 SoC family. > > Signed-off-by: Ludovic Desroches > --- > .../devicetree/bindings/iio/adc/at91_adc8xx.txt| 27 ++ > drivers/iio/adc/Kconfig| 11 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/at91_adc8xx.c | 417 > + > 4 files changed, 456 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt > create mode 100644 drivers/iio/adc/at91_adc8xx.c > > diff --git a/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt > b/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt > new file mode 100644 > index 000..64ad6a5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/iio/adc/at91_adc8xx.txt > @@ -0,0 +1,27 @@ > +* AT91 SAMA5D2 Analog to Digital Converter (ADC) > + > +Required properties: > + - compatible: Should be "atmel,sama5d2-adc". > + - reg: Should contain ADC registers location and length. > + - interrupts: Should contain the IRQ line for the ADC. > + - clocks: phandles to clocks. > + - clock-names: tuple listing clock names. > + Required elements: "adc_clk", "adc_op_clk". "adc_clk" is the peripheral > + clock, "adc_clk" is the sampling clock. > + - vref-supply: Supply used as reference for conversions. > + > +Optional properties: > + - vddana-supply: Supply for the adc device. What makes a supply optional? If chip dependent, then then you need a more specific compatible string. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v11 03/19] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count
Hi Jingoo,
Thanks for your respond.
On 12/22/2015 08:09 PM, Jingoo Han wrote:
On Wednesday, December 16, 2015 12:28 PM, Yakir Yang wrote:
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
directly, but we can take those as hardware limite. For example, RK3288
only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
like "link-rate = 0x0a" "lane-count = 4". (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a05c2b..6f899cd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
analogix_dp_device *dp,
/*
* For DP rev.1.1, Maximum link rate of Main Link lanes
* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
*/
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
- (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+ (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+ (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
- analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
- analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 8e84208..57aa4b0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
#define MAX_EQ_LOOP 5
enum link_rate_type {
- LINK_RATE_1_62GBPS = 0x06,
- LINK_RATE_2_70GBPS = 0x0a
+ LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+ LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+ LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
Then, how about removing 'enum link_rate_type'?
If DP_LINK_BW_* are used, LINK_RATE_* are not necessary.
Sure, good catch.
Thanks,
- Yakir
Best regards,
Jingoo Han
};
enum link_lane_count_type {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 02/19] drm: bridge: analogix/dp: fix some obvious code style
On 12/22/2015 08:05 PM, Jingoo Han wrote:
On Wednesday, December 16, 2015 12:26 PM, Yakir Yang wrote:
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
Acked-by: Jingoo Han
Thanks,
- Yakir
Best regards,
Jingoo Han
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
uncommon style like bellow: (Joe Preches)
- retval = exynos_dp_read_bytes_from_i2c(...
...);
+ retval =
+ exynos_dp_read_bytes_from_i2c(..);
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 72 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 124 ++--
3 files changed, 163 insertions(+), 162 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index fb8bda8..4a05c2b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
- if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+ if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
- EDID_EXTENSION_FLAG,
- _block);
+ EDID_EXTENSION_FLAG,
+ _block);
if (retval)
return retval;
@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
/* Read EDID data */
- retval = analogix_dp_read_bytes_from_i2c(dp,
I2C_EDID_DEVICE_ADDR,
+ retval = analogix_dp_read_bytes_from_i2c(dp,
+ I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
}
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
- _vector);
+ _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
*dp)
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
- I2C_EDID_DEVICE_ADDR,
- EDID_HEADER_PATTERN,
- EDID_BLOCK_LENGTH,
- [EDID_HEADER_PATTERN]);
+ I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+ EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct
analogix_dp_device *dp)
return -EIO;
}
- analogix_dp_read_byte_from_dpcd(dp,
- DP_TEST_REQUEST,
- _vector);
+ analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+ _vector);
if (test_vector &
Re: [PATCH v11 09/19] phy: Add driver for rockchip Display Port PHY
Hi Jingoo,
Thanks for your respond.
On 12/22/2015 08:20 PM, Jingoo Han wrote:
On Wednesday, December 16, 2015 12:41 PM, Yakir Yang wrote:
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
---
Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
the exist "grf" syscon already. And rename the example DT node from
"edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
struct" to "static const struct". And correct the input paramters of
devm_phy_create() interfaces. (Heiko)
Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
function, move those code to probe() method. And remove driver .owner
number. (Kishon)
Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
power control. (Heiko)
Changes in v2: None
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-rockchip-dp.c | 151 ++
3 files changed, 159 insertions(+)
create mode 100644 drivers/phy/phy-rockchip-dp.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
Enable this to support the Rockchip USB 2.0 PHY.
+config PHY_ROCKCHIP_DP
+ tristate "Rockchip Display Port PHY Driver"
+ depends on ARCH_ROCKCHIP && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the Rockchip Display Port PHY.
+
config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
phy-s5pv210-usb2.o
obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..3cb3bf8
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Please order these headers alphabetically.
It will enhance the readability.
Done,
Thanks,
- Yakir
Best regards,
Jingoo Han
+
+#define GRF_SOC_CON12 0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
+
+struct rockchip_dp_phy {
+ struct device *dev;
+ struct regmap *grf;
+ struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+ struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+ int ret;
+
+ if (enable) {
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+ GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+ GRF_EDP_PHY_SIDDQ_ON);
+ if (ret < 0) {
+ dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(dp->phy_24m);
+ } else {
+ clk_disable_unprepare(dp->phy_24m);
+
+ ret = regmap_write(dp->grf, GRF_SOC_CON12,
+
Re: [PATCH v11 06/19] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
On 12/22/2015 08:13 PM, Jingoo Han wrote:
On Wednesday, December 16, 2015 12:35 PM, Yakir Yang wrote:
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
Reviewed-by: Jingoo Han < jingooh...@gmail.com >
Thanks,
- Yakir
Best regards,
Jingoo Han
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
- hpd-gpio = < 6 0>;
+ hpd-gpios = < 6 0>;
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)
Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
7 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
{
status = "okay";
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
{
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-
common.dtsi
index 5cb33ba..b96624b 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
- samsung,hpd-gpio = < 0 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
};
{
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2f37c87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = < 6 GPIO_ACTIVE_HIGH>;
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git
Re: [PATCH v3 5/5] hisilicon/dts: Add hi655x pmic dts node
On Mon, Dec 21, 2015 at 02:20:16PM +0800, chenfeng wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > While doing this in driver code, I found that it seems all the vendor > chip have the voltage table. So I am wondering can we add this into > the regulator framework. > We can add in the function of_get_regulation_constraints to get the > vset table. > I am not sure this is right or not. I'm just not convinced it's a good pattern to move this data out to DT, like I said in my other mail it's making the ABI bigger and I'm not sure I see much upside over putting the data in a table in DT rather than in C code. It's more parsing code and more things we really shouldn't change in future. signature.asc Description: PGP signature
Re: [PATCH 2/2] pci, pcie-thunder-pem: Add PCIe host driver for ThunderX processors.
On Mon, Dec 21, 2015 at 05:53:42PM -0800, David Daney wrote:
> From: David Daney
>
> Some Cavium ThunderX processors require quirky access methods for the
> config space of the PCIe bridge. Add a driver to provide these config
> space accessor functions. The pci-host-generic driver code is used to
> configure the PCI machinery.
>
> Signed-off-by: David Daney
> ---
> .../devicetree/bindings/pci/pcie-thunder-pem.txt | 43
> drivers/pci/host/Kconfig | 6 +
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/pcie-thunder-pem.c| 283
> +
> 4 files changed, 333 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
> create mode 100644 drivers/pci/host/pcie-thunder-pem.c
>
> diff --git a/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
> b/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
> new file mode 100644
> index 000..66824d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pcie-thunder-pem.txt
> @@ -0,0 +1,43 @@
> +* ThunderX PEM PCIe host controller
> +
> +Firmware-initialized PCIe host controller found on some Cavium
> +ThunderX processors.
> +
> +The properties and their meanings are identical to those described in
> +host-heneric-pci.txt except as listed below.
s/heneric/generic/
> +
> +Properties of the host controller node that differ from
> +host-heneric-pci.txt:
ditto
> +
> +- compatible : Must be "cavium,pci-host-thunder-pem"
pcie rather than pci?
> +
> +- reg: Two entries: First the configuration space for down
> + stream devices base address and size, as accessed
> + from the parent bus. Second, the register bank of
> + the PEM device PCIe bridge.
> +
> +Example:
> +
> +pem2 {
pcie-controller@...
> + compatible = "cavium,pci-host-thunder-pem";
> + device_type = "pci";
> + msi-parent = <>;
> + msi-map = <0 0x1 0x1>;
> + bus-range = <0x8f 0xc7>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> +
> + reg = <0x8880 0x8f00 0x0 0x3900>, /* Configuration space */
> + <0x87e0 0xc200 0x0 0x0001>; /* PEM space */
> + ranges = <0x0100 0x00 0x0002 0x88b0 0x0002 0x00
> 0x0001>, /* I/O */
> + <0x0300 0x00 0x1000 0x8890 0x1000 0x0f
> 0xf000>, /* mem64 */
> + <0x4300 0x10 0x 0x88a0 0x 0x10
> 0x>, /* mem64-pref */
> + <0x0300 0x87e0 0xc2f0 0x87e0 0xc200 0x00
> 0x0010>; /* mem64 PEM BAR4 */
> +
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 0 0 0 24 4>, /* INTA */
> + <0 0 0 2 0 0 0 25 4>, /* INTB */
> + <0 0 0 3 0 0 0 26 4>, /* INTC */
> + <0 0 0 4 0 0 0 27 4>; /* INTD */
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 66/77] ncr5380: Fix soft lockups
I'd like to think that, too - probably true for the Atari TT SCSI case (can do scatter-gather, can do more than one command per LUN). Worse for the Falcon SCSI which is the only one I can test (no scatter-gather, one command per LUN, interrupt shared with IDE and IDE driver locked out while SCSI command handled). But that only affects balancing of I/O between IDE and SCSI drivers. Is that what you are worried about, Alan? Happy to test whether limiting max_sectors makes a difference in the DMA case. Cheers, Michael On Wed, Dec 23, 2015 at 2:47 AM, Finn Thain wrote: > > On Tue, 22 Dec 2015, One Thousand Gnomes wrote: > >> On Tue, 22 Dec 2015 12:18:44 +1100 Finn Thain >> wrote: >> >> > Because of the rudimentary design of the chip, it is necessary to poll >> > the SCSI bus signals during PIO and this tends to hog the CPU. The >> > driver will accept new commands while others execute, and this causes >> > a soft lockup because the workqueue item will not terminate until the >> > issue queue is emptied. >> > >> > When exercising dmx3191d using sequential IO from dd, the driver is >> > sent 512 KiB WRITE commands and 128 KiB READs. For a PIO transfer, the >> > rate is is only about 300 KiB/s, so these are long-running commands. >> > And although PDMA may run at several MiB/s, interrupts are disabled >> > for the duration of the transfer. >> > >> > Fix the unresponsiveness and soft lockup issues by calling >> > cond_resched() after each command is completed and by limiting >> > max_sectors for drivers that don't implement real DMA. >> >> Is there a reason for not doing some limiting in the DMA case too. A >> 512K write command even with DMA on a low end 68K box introduces a >> second of latency before another I/O can be scheduled ? > > The DMA case is the atari_scsi case. I'd like to think that atari_scsi > would have only the latency issues that might be expected from any SCSI-2 > host adapter driver. > > Unlike PDMA, interrupts are not disabled for these DMA transfers. Note > that this patch isn't really relevant to DMA, because the main loop > iterates only when done == 0, that is, !hostdata->dmalen. > > -- > >> >> Alan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mmc: sdhci-pci: Add AMD HS200 mode tuning function
2015-12-22 17:52 GMT+08:00 Andy Shevchenko :
> On Tue, Dec 22, 2015 at 6:40 PM, Wan Zongshun wrote:
>> From: Wan Zongshun
>>
>> This patch is to add software tuning functions for AMD hs200
>> mode.
>>
>> Signed-off-by: Wan Zongshun
>> ---
>> drivers/mmc/host/sdhci-pci-core.c | 146
>> ++
>> 1 file changed, 146 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-pci-core.c
>> b/drivers/mmc/host/sdhci-pci-core.c
>> index 08f4a9f..01c5723 100644
>> --- a/drivers/mmc/host/sdhci-pci-core.c
>> +++ b/drivers/mmc/host/sdhci-pci-core.c
>> @@ -729,6 +729,152 @@ enum amd_chipset_gen {
>> AMD_CHIPSET_UNKNOWN,
>> };
>>
>> +struct tuning_descriptor {
>> + unsigned char tune_around;
>> + bool this_tune_ok;
>> + bool last_tune_ok;
>> + bool valid_front_end;
>> + unsigned char valid_front;
>> + unsigned char valid_window_max;
>> + unsigned char tune_low_max;
>> + unsigned char tune_low;
>> + unsigned char valid_window;
>> + unsigned char tune_result;
>> +};
>> +
>> +#define AMD_EMMC_TUNE_REG 0xb8
>> +static struct tuning_descriptor tdescriptor;
>
> Global variable?!
Okay, will change it to local.
>
>> +
>> +static int tuning_reset(struct sdhci_host *host)
>
> Better prefixes?
Do you mean I should not name this function to tuning reset?
>
>> +{
>> + unsigned int val;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> +
>> + val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>> + val |= SDHCI_CTRL_PRESET_VAL_ENABLE | SDHCI_CTRL_EXEC_TUNING;
>> + sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
>> +
>> + val = sdhci_readw(host, SDHCI_HOST_CONTROL2);
>> + val &= ~SDHCI_CTRL_EXEC_TUNING;
>> + sdhci_writew(host, val, SDHCI_HOST_CONTROL2);
>> +
>> + spin_unlock_irqrestore(>lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +static int config_tuning_phase(struct sdhci_host *host, unsigned char phase)
>> +{
>> + struct sdhci_pci_slot *slot = sdhci_priv(host);
>> + struct pci_dev *pdev = slot->chip->pdev;
>> + unsigned int val;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> +
>> + pci_read_config_dword(pdev, AMD_EMMC_TUNE_REG, );
>> + val &= ~0xf;
>> + val |= (0x10800 | phase);
>
> Magic.
Okay, I will make 0x10800 to be see more clearly, will define each bit
Macro for it.
>
>> + pci_write_config_dword(pdev, AMD_EMMC_TUNE_REG, val);
>> +
>> + spin_unlock_irqrestore(>lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +static int find_good_phase(struct sdhci_host *host)
>> +{
>> + struct tuning_descriptor *td =
>> + struct sdhci_pci_slot *slot = sdhci_priv(host);
>> + struct pci_dev *pdev = slot->chip->pdev;
>> + unsigned int val;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> +
>> + if (td->this_tune_ok == false)
>> + td->valid_front_end = 1;
>> +
>> + if (td->valid_front_end)
>> + td->valid_front = td->valid_front;
>> + else if (td->this_tune_ok)
>> + td->valid_front = td->valid_front + 1;
>> +
>> + if ((!td->this_tune_ok && td->last_tune_ok) ||
>> + (td->tune_around == 11)) {
>
> Magic.
>
>> + if (td->valid_window > td->valid_window_max) {
>> + td->valid_window_max = td->valid_window;
>> + td->tune_low_max = td->tune_low;
>> + }
>> + }
>> +
>> + if (td->this_tune_ok) {
>> + if (!td->last_tune_ok)
>> + td->tune_low = td->tune_around;
>> + td->valid_window = td->valid_window + 1;
>> + } else {
>> + if (td->last_tune_ok)
>> + td->valid_window = 0x0;
>> + }
>> +
>> + td->last_tune_ok = td->this_tune_ok;
>> +
>> + if (td->tune_around == 11) {
>> + if ((td->valid_front + td->valid_window) >
>> + td->valid_window_max) {
>> + if (td->valid_front > td->valid_window)
>> + td->tune_result =
>> + ((td->valid_front - td->valid_window) >> 1);
>> + else
>> + td->tune_result = td->tune_low +
>> + ((td->valid_window + td->valid_front) >> 1);
>> + } else {
>> + td->tune_result =
>> + td->tune_low_max + (td->valid_window_max >>
>> 1);
>> + }
>> +
>> + if (td->tune_result > 0x0b)
>> + td->tune_result = 0x0b;
>> +
>> + pci_read_config_dword(pdev, AMD_EMMC_TUNE_REG, );
>> + val &= ~0xf;
>> + val |= (0x10800 | td->tune_result);
>
> Magic.
>
>> +
[PATCH v3 2/6] drivers/staging/lustre: Fix set-but-unused whinge.
drivers/staging/lustre/lustre/fid/lproc_fid.c: In function 'ldebugfs_fid_write_common': drivers/staging/lustre/lustre/fid/lproc_fid.c:67:6: warning: variable 'rc' set but not used [-Wunused-but-set-variable] int rc; We fix it by *using* the return code to help bulletproof it. It says it's test code - it should be *more* bulletproof than production, not less. Signed-off-by: Valdis Kletnieks --- drivers/staging/lustre/lustre/fid/lproc_fid.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/lustre/lustre/fid/lproc_fid.c b/drivers/staging/lustre/lustre/fid/lproc_fid.c index ce90c1c54a63..eff011f30fa5 100644 --- a/drivers/staging/lustre/lustre/fid/lproc_fid.c +++ b/drivers/staging/lustre/lustre/fid/lproc_fid.c @@ -85,6 +85,8 @@ ldebugfs_fid_write_common(const char __user *buffer, size_t count, rc = sscanf(kernbuf, "[%llx - %llx]\n", (unsigned long long *)_start, (unsigned long long *)_end); + if (rc != 2) + return -EINVAL; if (!range_is_sane() || range_is_zero() || tmp.lsr_start < range->lsr_start || tmp.lsr_end > range->lsr_end) return -EINVAL; -- 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 v3 1/6] drivers/staging/lustre: Silence warning about 'inline'
Low-hanging fruit first:
CC [M] drivers/staging/lustre/lustre/fid/fid_request.o
In file included from
drivers/staging/lustre/lustre/fid/../include/lustre_net.h:66:0,
from
drivers/staging/lustre/lustre/fid/../include/lustre_lib.h:64,
from drivers/staging/lustre/lustre/fid/../include/obd.h:52,
from drivers/staging/lustre/lustre/fid/fid_request.c:48:
drivers/staging/lustre/lustre/fid/../include/lu_object.h:765:1: warning:
'inline' is not at beginning of declaration [-Wold-style-declaration]
static const inline struct lu_device_operations *
^
So we just swap inline and const. 272 warnings gone. :)
Signed-off-by: Valdis Kletnieks
---
drivers/staging/lustre/lustre/include/lu_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/include/lu_object.h
b/drivers/staging/lustre/lustre/include/lu_object.h
index fa78689748a9..176724f60c1b 100644
--- a/drivers/staging/lustre/lustre/include/lu_object.h
+++ b/drivers/staging/lustre/lustre/include/lu_object.h
@@ -756,7 +756,7 @@ static inline const struct lu_fid *lu_object_fid(const
struct lu_object *o)
/**
* return device operations vector for this object
*/
-static const inline struct lu_device_operations *
+static inline const struct lu_device_operations *
lu_object_ops(const struct lu_object *o)
{
return o->lo_dev->ld_ops;
--
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 v3 4/6] drivers/staging/lustre: Fix another C compiler whine: set but not used
CC [M] drivers/staging/lustre/lustre/libcfs/module.o
drivers/staging/lustre/lustre/libcfs/module.c: In function
'lustre_insert_debugfs':
drivers/staging/lustre/lustre/libcfs/module.c:670:17: warning: variable 'entry'
set but not used [-Wunused-but-set-variable]
struct dentry *entry;
^
Just ignore the dentry returned, and add a comment that we *know*
we're not really leaking the dentry because something else will be able
to reap it via recursion.
Signed-off-by: Valdis Kletnieks
---
drivers/staging/lustre/lustre/libcfs/module.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
b/drivers/staging/lustre/lustre/libcfs/module.c
index 96d9d4651a51..4438dc426b54 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -667,8 +667,6 @@ static const struct file_operations
lnet_debugfs_file_operations = {
void lustre_insert_debugfs(struct ctl_table *table,
const struct lnet_debugfs_symlink_def *symlinks)
{
- struct dentry *entry;
-
if (lnet_debugfs_root == NULL)
lnet_debugfs_root = debugfs_create_dir("lnet", NULL);
@@ -676,15 +674,17 @@ void lustre_insert_debugfs(struct ctl_table *table,
if (IS_ERR_OR_NULL(lnet_debugfs_root))
return;
+ /* We don't save the dentry returned in next two calls, because
+* we don't call debugfs_remove() but rather remove_recursive()
+*/
for (; table->procname; table++)
- entry = debugfs_create_file(table->procname, table->mode,
- lnet_debugfs_root, table,
- _debugfs_file_operations);
+ debugfs_create_file(table->procname, table->mode,
+ lnet_debugfs_root, table,
+ _debugfs_file_operations);
for (; symlinks && symlinks->name; symlinks++)
- entry = debugfs_create_symlink(symlinks->name,
- lnet_debugfs_root,
- symlinks->target);
+ debugfs_create_symlink(symlinks->name, lnet_debugfs_root,
+ symlinks->target);
}
EXPORT_SYMBOL_GPL(lustre_insert_debugfs);
--
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 v3 5/6] drivers/staging/lustre: Nuke an unsigned >= 0 assert
Writing asserts for almost-never-can-happen things can be valuable.
Writing an assert that tests that an "unsigned int" hasn't gone negative
isn't.
And it generates an *ugly* message:
drivers/staging/lustre/lustre/llite/rw.c:763:20: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
^
include/linux/compiler.h:137:45: note: in definition of macro 'unlikely'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x,
0))
^
drivers/staging/lustre/lustre/llite/rw.c:763:2: note: in expansion of macro
'LASSERTF'
LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
^
drivers/staging/lustre/lustre/llite/rw.c:763:20: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
^
include/linux/compiler.h:137:53: note: in definition of macro 'unlikely'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x,
0))
^
drivers/staging/lustre/lustre/llite/rw.c:763:2: note: in expansion of macro
'LASSERTF'
LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
^
drivers/staging/lustre/lustre/llite/rw.c:763:20: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
^
include/linux/compiler.h:110:47: note: in definition of macro 'likely_notrace'
#define likely_notrace(x) __builtin_expect(!!(x), 1)
^
include/linux/compiler.h:137:58: note: in expansion of macro '__branch_check__'
# define unlikely(x) (__builtin_constant_p(x) ? !!(x) : __branch_check__(x,
0))
^
drivers/staging/lustre/lustre/llite/../include/linux/../../../include/linux/libcfs/libcfs_private.h:58:6:
note: in expansion of macro 'unlikely'
if (unlikely(!(cond))) { \
^
drivers/staging/lustre/lustre/llite/rw.c:763:2: note: in expansion of macro
'LASSERTF'
LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
^
Umm, thank you, GCC. We'll delete the problem line so we never see that spew
again.
Signed-off-by: Valdis Kletnieks
---
drivers/staging/lustre/lustre/llite/rw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/rw.c
b/drivers/staging/lustre/lustre/llite/rw.c
index f79193fa2fb7..39390aab9da2 100644
--- a/drivers/staging/lustre/lustre/llite/rw.c
+++ b/drivers/staging/lustre/lustre/llite/rw.c
@@ -764,7 +764,6 @@ int ll_readahead(const struct lu_env *env, struct cl_io *io,
ret = ll_read_ahead_pages(env, io, queue,
ria, , mapping, _end);
- LASSERTF(reserved >= 0, "reserved %lu\n", reserved);
if (reserved != 0)
ll_ra_count_put(ll_i2sbi(inode), reserved);
--
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 v3 6/6] drivers/staging/lustre: Nuke another unsigned >= 0 assert
Clean up another case of the compiler remininding the programmer they
are an idiot:
drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c:308:34: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
LASSERT(page_pools.epp_waitqlen >= 0);
Just lose the assert, and save a page of compiler spew.
Signed-off-by: Valdis Kletnieks
---
drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
b/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
index cd8a9987f7ac..1f326673f089 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c
@@ -304,7 +304,6 @@ static unsigned long enc_pools_cleanup(struct page
***pools, int npools)
static inline void enc_pools_wakeup(void)
{
assert_spin_locked(_pools.epp_lock);
- LASSERT(page_pools.epp_waitqlen >= 0);
if (unlikely(page_pools.epp_waitqlen)) {
LASSERT(waitqueue_active(_pools.epp_waitq));
--
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 v2 2/2] dt-bindings: sound: add devicetree document for rt5616
On Tue, Dec 22, 2015 at 01:45:03PM +0800, Caesar Wang wrote: > Add the description for rt5616 codec. > > Signed-off-by: Caesar Wang > > --- > > Changes in v2: > - As Frank comments, rt5616@1b to instead of rt5616. > - Update the Pins device from Bard. > > Changes in v1: > - As Heiko comments, remove the not exist option properties. > > Documentation/devicetree/bindings/sound/rt5616.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/6] drivers/staging/lustre: Clean up another C warnining: set but not used
drivers/staging/lustre/lustre/fid/../include/lustre_cfg.h: In function
'lustre_cfg_free':
drivers/staging/lustre/lustre/fid/../include/lustre_cfg.h:253:6: warning:
variable 'len' set but not used [-Wunused-but-set-variable]
int len;
Yep, we're just gonna call kfree, no need to calculate len. Bye-bye.
Signed-off-by: Valdis Kletnieks
---
drivers/staging/lustre/lustre/include/lustre_cfg.h | 4 --
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_cfg.h
b/drivers/staging/lustre/lustre/include/lustre_cfg.h
index eb6b292b7b25..d30d8b054c92 100644
--- a/drivers/staging/lustre/lustre/include/lustre_cfg.h
+++ b/drivers/staging/lustre/lustre/include/lustre_cfg.h
@@ -252,10 +252,6 @@ static inline struct lustre_cfg *lustre_cfg_new(int cmd,
static inline void lustre_cfg_free(struct lustre_cfg *lcfg)
{
- int len;
-
- len = lustre_cfg_len(lcfg->lcfg_bufcount, lcfg->lcfg_buflens);
-
kfree(lcfg);
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] selftests/cgroupns: new test for cgroup namespaces
Quoting Alban Crequy (alban.cre...@gmail.com):
> From: Alban Crequy
>
> This adds the selftest "cgroupns_test" in order to test the CGroup
> Namespace patchset.
>
> cgroupns_test creates two child processes. They perform a list of
> actions defined by the array cgroupns_test. This array can easily be
> extended to more scenarios without adding much code. They are
> synchronized with eventfds to ensure only one action is performed at a
> time.
>
> The memory is shared between the processes (CLONE_VM) so each child
> process can know the pid of their siblings without extra IPC.
>
> The output explains the scenario being played. Short extract:
>
> > current cgroup: /user.slice/user-0.slice/session-1.scope
> > child process #0: check that process #self (pid=482) has cgroup
> > /user.slice/user-0.slice/session-1.scope
> > child process #0: unshare cgroupns
> > child process #0: move process #self (pid=482) to cgroup
> > cgroup-a/subcgroup-a
> > child process #0: join parent cgroupns
>
> The test does not change the mount namespace and does not mount any
> new cgroup2 filesystem. Therefore this does not test that the cgroup2
> mount is correctly rooted to the cgroupns root at mount time.
>
> Signed-off-by: Alban Crequy
>
> ---
>
> This patch is available in the cgroupns.v7-tests branch of
> https://github.com/kinvolk/linux.git
> It is based on top of Serge Hallyn's cgroupns.v7 branch of
> https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/
>
> I see Linux does not have a lot of selftests and there are more Linux
> container tests in Linux Test Project:
> https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/containers
>
> Is it better to send this test here or to LTP?
> ---
> tools/testing/selftests/Makefile | 1 +
> tools/testing/selftests/cgroupns/Makefile| 11 +
> tools/testing/selftests/cgroupns/cgroupns_test.c | 378
> +++
> 3 files changed, 390 insertions(+)
> create mode 100644 tools/testing/selftests/cgroupns/Makefile
> create mode 100644 tools/testing/selftests/cgroupns/cgroupns_test.c
>
> diff --git a/tools/testing/selftests/Makefile
> b/tools/testing/selftests/Makefile
> index c8edff6..694325a 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -1,4 +1,5 @@
> TARGETS = breakpoints
> +TARGETS += cgroupns
> TARGETS += cpu-hotplug
> TARGETS += efivarfs
> TARGETS += exec
> diff --git a/tools/testing/selftests/cgroupns/Makefile
> b/tools/testing/selftests/cgroupns/Makefile
> new file mode 100644
> index 000..0fdbe0a
> --- /dev/null
> +++ b/tools/testing/selftests/cgroupns/Makefile
> @@ -0,0 +1,11 @@
> +CFLAGS += -I../../../../usr/include/
> +CFLAGS += -I../../../../include/uapi/
> +
> +all: cgroupns_test
> +
> +TEST_PROGS := cgroupns_test
> +
> +include ../lib.mk
> +
> +clean:
> + $(RM) cgroupns_test
> diff --git a/tools/testing/selftests/cgroupns/cgroupns_test.c
> b/tools/testing/selftests/cgroupns/cgroupns_test.c
> new file mode 100644
> index 000..d45017c
> --- /dev/null
> +++ b/tools/testing/selftests/cgroupns/cgroupns_test.c
> @@ -0,0 +1,378 @@
> +#define _GNU_SOURCE
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "../kselftest.h"
> +
> +#define STACK_SIZE 65536
> +
> +static char root_cgroup[4096];
> +
> +#define CHILDREN_COUNT 2
> +typedef struct {
> + int pid;
> + uint8_t *stack;
> + int start_semfd;
> + int end_semfd;
> +} cgroupns_child_t;
> +cgroupns_child_t children[CHILDREN_COUNT];
> +
> +typedef enum {
> + UNSHARE_CGROUPNS,
> + JOIN_CGROUPNS,
> + CHECK_CGROUP,
> + CHECK_CGROUP_WITH_ROOT_PREFIX,
> + MOVE_CGROUP,
> + MOVE_CGROUP_WITH_ROOT_PREFIX,
> +} cgroupns_action_t;
> +
> +static const struct {
> + int actor_pid;
> + cgroupns_action_t action;
> + int target_pid;
> + char *path;
> +} cgroupns_tests[] = {
> + { 0, CHECK_CGROUP_WITH_ROOT_PREFIX, -1, ""},
> + { 0, CHECK_CGROUP_WITH_ROOT_PREFIX, 0, ""},
> + { 0, CHECK_CGROUP_WITH_ROOT_PREFIX, 1, ""},
> + { 1, CHECK_CGROUP_WITH_ROOT_PREFIX, -1, ""},
> + { 1, CHECK_CGROUP_WITH_ROOT_PREFIX, 0, ""},
> + { 1, CHECK_CGROUP_WITH_ROOT_PREFIX, 1, ""},
> +
> + { 0, UNSHARE_CGROUPNS, -1, NULL},
> +
> + { 0, CHECK_CGROUP, -1, "/"},
> + { 0, CHECK_CGROUP, 0, "/"},
> + { 0, CHECK_CGROUP, 1, "/"},
> + { 1, CHECK_CGROUP_WITH_ROOT_PREFIX, -1, ""},
> + { 1, CHECK_CGROUP_WITH_ROOT_PREFIX, 0, ""},
> + { 1, CHECK_CGROUP_WITH_ROOT_PREFIX, 1, ""},
> +
> + { 1, UNSHARE_CGROUPNS, -1, NULL},
> +
> + { 0, CHECK_CGROUP, -1, "/"},
> + { 0, CHECK_CGROUP, 0, "/"},
> + { 0, CHECK_CGROUP, 1, "/"},
> + { 1, CHECK_CGROUP, -1, "/"},
> + { 1, CHECK_CGROUP, 0, "/"},
> + { 1, CHECK_CGROUP, 1, "/"},
> +
> +
[PATCH v3 0/6] Patch series to make lustre safe(r) for W=1 compiles
Start of a batch series to clean up the Lustre tree. Other people have done some sparse and checkpatch cleanups, but I found a bunch of stuff building with W=1. There's probably more, but this was the really low-hanging obvious fruit. Valdis Kletnieks (6): drivers/staging/lustre: Silence warning about 'inline' drivers/staging/lustre: Fix set-but-unused whinge. drivers/staging/lustre: Clean up another C warnining: set but not used drivers/staging/lustre: Fix another C compiler whine: set but not used drivers/staging/lustre: Nuke an unsigned >= 0 assert drivers/staging/lustre: Nuke another unsigned >= 0 assert drivers/staging/lustre/lustre/fid/lproc_fid.c | 1 + drivers/staging/lustre/lustre/include/lu_object.h | 2 +- drivers/staging/lustre/lustre/include/lustre_cfg.h | 4 -- drivers/staging/lustre/lustre/libcfs/module.c | 15 drivers/staging/lustre/lustre/llite/rw.c | 1 - drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c| 1 - 6 files changed, 9 insertions(+), 15 deletions(-) V2: Add Greg HK to recipient list V3: fix missing prefix in Subject: lines... -- 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 v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA
On 12/22/2015 02:37 AM, Geert Uytterhoeven wrote:
Hi Kees, Russell,
On Wed, Dec 2, 2015 at 9:27 PM, Kees Cook wrote:
The use of CONFIG_DEBUG_RODATA is generally seen as an essential part of
kernel self-protection:
http://www.openwall.com/lists/kernel-hardening/2015/11/30/13
Additionally, its name has grown to mean things beyond just rodata. To
get ARM closer to this, we ought to rearrange the names of the configs
that control how the kernel protects its memory. What was called
CONFIG_ARM_KERNMEM_PERMS is really doing the work that other architectures
call CONFIG_DEBUG_RODATA.
[...]
This broke s2ram with shmobile_defconfig on r8a7791/koelsch:
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
PM: suspend of devices complete after 112.157 msecs
PM: late suspend of devices complete after 1.605 msecs
PM: noirq suspend of devices complete after 13.098 msecs
Disabling non-boot CPUs ...
s---[ end Kernel panic - not syncing: Attempted to kill the idle task!
CPU0: stopping
CPU: 0 PID: 2412 Comm: s2ram Tainted: G D
4.4.0-rc6-3-g1bb20571dcf0edfc #470
Hardware name: Generic R8A7791 (Flattened Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
r6: r5: r4: r3:80404000
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (handle_IPI+0xf4/0x19c)
r4:c09313f0 r3:c09091ec
[] (handle_IPI) from [] (gic_handle_irq+0x7c/0x98)
r7:c0910b80 r6:ee1d5c30 r5:c0902754 r4:f0802000
[] (gic_handle_irq) from [] (__irq_svc+0x54/0x70)
Exception stack(0xee1d5c30 to 0xee1d5c78)
5c20: c0955484 0002
60070013
5c40: c0942718 c093916c 0005 000f
c0943088 ee1d5cd4
5c60: ee1d5c08 ee1d5c80 c033fc20 c0158120 60070013
r8: r7:ee1d5c64 r6: r5:60070013 r4:c0158120 r3:c033fc20
[] (console_unlock) from [] (vprintk_emit+0x448/0x4a4)
r10:c09450a6 r9: r8:000e r7:0005 r6:0006 r5:c0932758
r4:0001
[] (vprintk_emit) from [] (vprintk_default+0x28/0x30)
r10:c09055e0 r9:0001 r8:c09055e0 r7:0010 r6: r5:
r4:0001
[] (vprintk_default) from [] (printk+0x34/0x40)
[] (printk) from [] (__cpu_die+0x34/0x78)
r3:0003 r2:c0906808 r1:0001 r0:c0710af6
[] (__cpu_die) from [] (_cpu_down+0x168/0x290)
r4:0001 r3:0005
[] (_cpu_down) from [] (disable_nonboot_cpus+0x70/0xf0)
r10:0051 r9:c0932734 r8:c0902528 r7: r6:c090245c r5:c0931b40
r4:0001
[] (disable_nonboot_cpus) from []
(suspend_devices_and_enter+0x290/0x3f8)
r8:c0714bb5 r7:eebac300 r6:0003 r5:c0932734 r4: r3:
[] (suspend_devices_and_enter) from []
(pm_suspend+0xb4/0x1c8)
r9:c093273c r8:c0714bb5 r7:eebac300 r6:0003 r5:c09576fc r4:
[] (pm_suspend) from [] (state_store+0xb0/0xc4)
r6:0004 r5:0003 r4:0003 r3:006d
[] (state_store) from [] (kobj_attr_store+0x1c/0x28)
r9:000cdc08 r8:ee1d5f80 r7:eebacb0c r6:eebacb00 r5:eebac300 r4:eebac300
[] (kobj_attr_store) from [] (sysfs_kf_write+0x44/0x50)
[] (sysfs_kf_write) from []
(kernfs_fop_write+0x13c/0x1a0)
r4:0004 r3:c02223f4
[] (kernfs_fop_write) from [] (__vfs_write+0x34/0xdc)
r10: r9:ee1d4000 r8:c0106fa4 r7:0004 r6:ee1d5f80 r5:c02219a4
r4:edf85d00
[] (__vfs_write) from [] (vfs_write+0xb8/0x140)
r7:ee1d5f80 r6:000cdc08 r5:edf85d00 r4:0004
[] (vfs_write) from [] (SyS_write+0x50/0x90)
r9:ee1d4000 r8:c0106fa4 r7:000cdc08 r6:0004 r5:edf85d00 r4:edf85d00
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)
Before commit 1bb20571dcf0edfc ("ARM: 8470/1: mm: flip priority of
CONFIG_DEBUG_RODATA"):
# CONFIG_ARM_KERNMEM_PERMS is not set
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
PM: suspend of devices complete after 112.163 msecs
PM: late suspend of devices complete after 1.610 msecs
PM: noirq suspend of devices complete after 13.109 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
After the offending commit:
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_ALIGN_RODATA=y
The "problem" is that DEBUG_RODATA now defaults to y on CPU_V7, so it gets
enabled for shmobile_defconfig. If I manually disable DEBUG_RODATA again,
s2ram does work.
The real problem is something else, though. I can trigger the same panic
without the offending commit by enabling:
CONFIG_ARM_KERNMEM_PERMS=y
CONFIG_DEBUG_RODATA=y
I never enabled those options before, so I have no idea if this is a recent
regression. I've just tried a few older versions: on v4.4-rc1 I see the same
Re: [PATCH 2/5] watchdog: Separate and maintain variables based on variable lifetime
On 12/22/2015 02:05 PM, Tomas Winkler wrote: > Do you see a situation where holding the lock between calls into the driver > might be a problem ? I don't think u are holding the lock now in watchdog_unregister when WDOG_UNREGISTERED was dropped. the lock is held while clearing the pointers: mutex_lock(_data->lock); wd_data->wdd = NULL; wdd->wd_data = NULL; mutex_unlock(_data->lock); Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/6] dt-bindings: misc: add document for reboot-mode driver
On Tue, Dec 22, 2015 at 05:05:24PM +0800, Andy Yan wrote:
> add device tree bindings document for reboot-mode driver
>
> Signed-off-by: Andy Yan
>
> ---
>
> Changes in v1: None
>
> .../devicetree/bindings/misc/reboot-mode.txt | 41
> ++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/reboot-mode.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/reboot-mode.txt
> b/Documentation/devicetree/bindings/misc/reboot-mode.txt
> new file mode 100644
> index 000..082bc0c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/reboot-mode.txt
> @@ -0,0 +1,41 @@
> +Generic reboot mode communication driver
You're not describing a driver. It is a mapping of boot modes to values.
> +
> +This driver get reboot mode arguments from userspace
Coming from userspace is a Linuxism.
> +and stores it in special register or ram . Then the
> +bootloader will read it and take different action
> +according the argument stored.
> +
> +Required properties:
> +- compatible = "reboot-mode" or other vendor compatible string;
> +
> +Each mode is represented as a sub-node of reboot_mode:
> +
> +Subnode required properties:
> +- linux,mode: reboot mode command,such as "loader","recovery",
> "fastboot".
> +- linux,magic: magic number for the mode, this is vendor specific.
> +
> +example:
> + reboot_mode {
> + compatible = "rockchip,reboot-mode";
> + rockchip,regmap = <>;
> + offset = <0x40>;
> + loader {
> + linux,mode = "loader";
> + linux,magic = <0x5242C301>;
> + };
These can be much more simply expressed as:
loader = <0x5242c301>;
I would like to see the property names here standardized as much as
possible. I'm not sure if we can define the properties as a u32 or need
some flexibility here.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gicv2m: Miscellaneous fixes for V2m resources and SPI ranges
This patch contain fixes for v2m resources and SPI ranges:
* Fix off-by-one error when set up v2m resource end range in
gicv2m_acpi_init().
* Fix the off-by-one print error for SPI range.
* Use %pR to properly print resource range information.
Both ACPI and DT should now print:
GICv2m: range[mem 0xe118-0xe1180fff], SPI[64:319]
Suggested-by: Bjorn Helgaas
Signed-off-by: Suravee Suthikulpanit
---
Hi Marc,
Sorry for this minor last minute fixup. This should go on top
of the V7 of the GICv2m ACPI patch series. Although, this is
not urgent.
Thanks,
Suravee
drivers/irqchip/irq-gic-v2m.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
index 7e2975d..5f346ea 100644
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -365,9 +365,8 @@ static int __init gicv2m_init_one(struct fwnode_handle
*fwnode,
list_add_tail(>entry, _nodes);
- pr_info("range[%#lx:%#lx], SPI[%d:%d]\n",
- (unsigned long)res->start, (unsigned long)res->end,
- v2m->spi_start, (v2m->spi_start + v2m->nr_spis));
+ pr_info("range%pR, SPI[%d:%d]\n", res,
+ v2m->spi_start, (v2m->spi_start + v2m->nr_spis - 1));
return 0;
err_iounmap:
@@ -456,7 +455,8 @@ acpi_parse_madt_msi(struct acpi_subtable_header *header,
return -EINVAL;
res.start = m->base_address;
- res.end = m->base_address + SZ_4K;
+ res.end = m->base_address + SZ_4K - 1;
+ res.flags = IORESOURCE_MEM;
if (m->flags & ACPI_MADT_OVERRIDE_SPI_VALUES) {
spi_start = m->spi_base;
--
2.1.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/
