Re: [PATCH] Documentation: minor typo fix in mailbox.txt
On Thu, Aug 13, 2015 at 06:04:11PM -0600, Jonathan Corbet wrote: > On Mon, 3 Aug 2015 09:30:25 +0800 > Leo Yan wrote: > > > Fix minor typo so that can pass correct pointer variable for > > container_of(). > > Looks good to me, applied to the docs tree. I also took the opportunity > to eliminate the (now) needless line-splitting on the affected lines. Yes, the line length is less than 78, so don't need splitting. Thanks, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] target: remove initiatorname field in se_acl_lun
From: Chris Zankel
The initiatorname field in se_acl_lun is only a copy of the same field
in se_node_acl, so remove it and use the version in se_node_acl where
needed (it's actually only used for pr_debug)
Signed-off-by: Chris Zankel
Signed-off-by: Spencer Baugh
---
drivers/target/target_core_device.c | 8 +++-
drivers/target/target_core_fabric_configfs.c | 2 +-
include/target/target_core_base.h| 1 -
3 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/target/target_core_device.c
b/drivers/target/target_core_device.c
index 09e682b..c4a8db6 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -620,8 +620,6 @@ struct se_lun_acl *core_dev_init_initiator_node_lun_acl(
lacl->mapped_lun = mapped_lun;
lacl->se_lun_nacl = nacl;
- snprintf(lacl->initiatorname, TRANSPORT_IQN_LEN, "%s",
-nacl->initiatorname);
return lacl;
}
@@ -656,7 +654,7 @@ int core_dev_add_initiator_node_lun_acl(
" InitiatorNode: %s\n", tpg->se_tpg_tfo->get_fabric_name(),
tpg->se_tpg_tfo->tpg_get_tag(tpg), lun->unpacked_lun,
lacl->mapped_lun,
(lun_access & TRANSPORT_LUNFLAGS_READ_WRITE) ? "RW" : "RO",
- lacl->initiatorname);
+ nacl->initiatorname);
/*
* Check to see if there are any existing persistent reservation APTPL
* pre-registrations that need to be enabled for this LUN ACL..
@@ -688,7 +686,7 @@ int core_dev_del_initiator_node_lun_acl(
" InitiatorNode: %s Mapped LUN: %llu\n",
tpg->se_tpg_tfo->get_fabric_name(),
tpg->se_tpg_tfo->tpg_get_tag(tpg), lun->unpacked_lun,
- lacl->initiatorname, lacl->mapped_lun);
+ nacl->initiatorname, lacl->mapped_lun);
return 0;
}
@@ -701,7 +699,7 @@ void core_dev_free_initiator_node_lun_acl(
" Mapped LUN: %llu\n", tpg->se_tpg_tfo->get_fabric_name(),
tpg->se_tpg_tfo->tpg_get_tag(tpg),
tpg->se_tpg_tfo->get_fabric_name(),
- lacl->initiatorname, lacl->mapped_lun);
+ lacl->se_lun_nacl->initiatorname, lacl->mapped_lun);
kfree(lacl);
}
diff --git a/drivers/target/target_core_fabric_configfs.c
b/drivers/target/target_core_fabric_configfs.c
index 48a3698..be42429 100644
--- a/drivers/target/target_core_fabric_configfs.c
+++ b/drivers/target/target_core_fabric_configfs.c
@@ -203,7 +203,7 @@ static ssize_t target_fabric_mappedlun_store_write_protect(
pr_debug("%s_ConfigFS: Changed Initiator ACL: %s"
" Mapped LUN: %llu Write Protect bit to %s\n",
se_tpg->se_tpg_tfo->get_fabric_name(),
- lacl->initiatorname, lacl->mapped_lun, (op) ? "ON" : "OFF");
+ se_nacl->initiatorname, lacl->mapped_lun, (op) ? "ON" : "OFF");
return count;
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index 0a7c44e..b59b61a 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -598,7 +598,6 @@ struct se_ml_stat_grps {
};
struct se_lun_acl {
- charinitiatorname[TRANSPORT_IQN_LEN];
u64 mapped_lun;
struct se_node_acl *se_lun_nacl;
struct se_lun *se_lun;
--
2.5.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] target: remove unused lun_flags field from se_lun
From: Chris Zankel
The lun_flags field is not used, so drop it.
Signed-off-by: Chris Zankel
Signed-off-by: Spencer Baugh
---
include/target/target_core_base.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index 17ae2d6..0a7c44e 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -685,7 +685,6 @@ struct se_lun {
#define SE_LUN_LINK_MAGIC 0x7771
u32 lun_link_magic;
u32 lun_access;
- u32 lun_flags;
u32 lun_index;
/* RELATIVE TARGET PORT IDENTIFER */
--
2.5.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warnings after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:
drivers/gpu/drm/exynos/exynos_drm_drv.c:290:2: warning: initialization from
incompatible pointer type
.get_vblank_counter = drm_vblank_count,
^
drivers/gpu/drm/exynos/exynos_drm_drv.c:290:2: warning: (near initialization
for 'exynos_drm_driver.get_vblank_counter')
drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: initialization from
incompatible pointer type
.get_vblank_counter = drm_vblank_count,
^
drivers/gpu/drm/rcar-du/rcar_du_drv.c:262:2: warning: (near initialization for
'rcar_du_driver.get_vblank_counter')
drivers/gpu/drm/msm/msm_drv.c:981:2: warning: initialization from incompatible
pointer type
.get_vblank_counter = drm_vblank_count,
^
drivers/gpu/drm/msm/msm_drv.c:981:2: warning: (near initialization for
'msm_driver.get_vblank_counter')
Introduced by commit
b90180b057f7 ("drm/irq: More pipe/crtc consistency cleanups")
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 man-pages 3/3] open.2: describe O_BENEATH flag
On 13 August 2015 at 19:38, Andy Lutomirski wrote: > On Thu, Aug 13, 2015 at 2:32 AM, David Drysdale wrote: >> Signed-off-by: David Drysdale > > What's the behavior wrt fcntl(F_GETFL, etc)? I would presume that O_BENEATH is one of the so-called "file creation flags". See this paragraph of the DESCRIPTION: In addition, zero or more file creation flags and file status flags can be bitwise-or'd in flags. The file creation flags are O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TMPFILE, O_TRUNC, and O_TTY_INIT. The file status flags are all of the remaining flags listed below. The distinction between these two groups of flags is that the file status flags can be retrieved and (in some cases) modified; see fcntl(2) for details. David, presuming this is correct (I can't see how O_BENEATH could be a "file *status* flag"), your patch should also add O_BENEATH to the list in that paragraph. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] crypto: qat - Don't move data inside output buffer
On Wed, Aug 12, 2015 at 08:54:45PM -0700, Tadeusz Struk wrote: > Don't need to move data inside of the output buffer > because SW doen't need to do this anymore sice the new MPI > mpi_read_buf() has been added. Just set the correct output len. > > Signed-off-by: Tadeusz Struk > --- > drivers/crypto/qat/qat_common/qat_asym_algs.c |3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c > b/drivers/crypto/qat/qat_common/qat_asym_algs.c > index fe352a6..6ddb13c 100644 > --- a/drivers/crypto/qat/qat_common/qat_asym_algs.c > +++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c > @@ -144,9 +144,6 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp) > ptr++; > } > > - if (areq->dst_len != req->ctx->key_sz) > - memcpy(areq->dst, ptr, areq->dst_len); > - This looks wrong. It appears to be trying to remove leading zeroes so you can't just change the length because then you end up removing the trailing digits equal to the number of leading zeroes. The existing code is also wrong as you should be using memmove instead of memcpy. 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] book3s_hv_rmhandlers:Pass the correct trap argument to kvmhv_commence_exit
On Thu, May 21, 2015 at 01:57:04PM +0530, Gautham R. Shenoy wrote: > In guest_exit_cont we call kvmhv_commence_exit which expects the trap > number as the argument. However r3 doesn't contain the trap number at > this point and as a result we would be calling the function with a > spurious trap number. > > Fix this by copying r12 into r3 before calling kvmhv_commence_exit as > r12 contains the trap number > > Signed-off-by: Gautham R. Shenoy Hi Gautham, I agree with your logic: r3 is quite clearly corrupted in that path. So: Reviewed-by: Sam Bobroff Just one comment: Do you have a case of this causing some visible problem due to the corrupted trap number? (I'll test the patch if you do.) Cheers, Sam. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/hwpoison: fix race between soft_offline_page and unpoison_memory
On 8/14/15 12:19 PM, Naoya Horiguchi wrote: > On Thu, Aug 13, 2015 at 06:27:40PM +0800, Wanpeng Li wrote: >> On 8/13/15 6:04 PM, Naoya Horiguchi wrote: >>> On Thu, Aug 13, 2015 at 05:18:56PM +0800, Wanpeng Li wrote: On 8/13/15 4:53 PM, Naoya Horiguchi wrote: >>> ... > I think that unpoison is used only in testing so this race never affects > our end-users/customers, so going back to this migratetype change stuff > looks unworthy to me. Migratetype stuff is just removed by you two months ago, then this bug occurs recently since the more and more patches which you fix some races. >>> Yes, this race (which existed before my recent changes) became more visible >> IIUC, no. The page will be freed before PageHWPoison is set. So the race >> doesn't exist. > OK ... > >>> with that changes. But I don't think that simply reverting them is a right >>> solution. >>> > If I read correctly, the old migratetype approach has a few problems: > 1) it doesn't fix the problem completely, because > set_migratetype_isolate() can fail to set MIGRATE_ISOLATE to the > target page if the pageblock of the page contains one or more > unmovable pages (i.e. has_unmovable_pages() returns true). > 2) the original code changes migratetype to MIGRATE_ISOLATE forcibly, > and sets it to MIGRATE_MOVABLE forcibly after soft offline, > regardless > of the original migratetype state, which could impact other > subsystems > like memory hotplug or compaction. Maybe we can add a "FIXME" comment on the Migratetype stuff, since the current linus tree calltrace and it should be fixed immediately, and I don't see obvious bugs appear on migratetype stuffs at least currently, so "FIXME" is enough. :-) >>> Sorry if confusing, but my intention in saying about "FIXME" comment was >>> that we can find another solution for this race rather than just reverting, >>> so adding comment about the reported bug in current code (keeping code from >>> 4491f712606) is OK for very short term. >>> I understand that leaving a race window of BUG_ON is not the best thing, but >>> as I said, this race shouldn't affect end-users, so this is not an urgent >>> bug. >>> # It's enough if testers know this. >> The 4.2 is coming, this patch can be applied as a temporal solution in >> order to fix the broken linus tree, and the any final solution can be >> figured out later. > I didn't reproduce this problem yet in my environment, but from code reading > I guess that checking PageHWPoison flag in unmap_and_move() like below could > avoid the problem. Could you testing with this, please? I have already try to modify unmap_and_move() the same as what you do before I post migratetype stuff. It doesn't work and have other calltrace. Regards, Wanpeng Li > > Thanks, > Naoya Horiguchi > --- > From: Naoya Horiguchi > Date: Fri, 14 Aug 2015 08:04:03 +0900 > Subject: [PATCH] mm: hwpoison: migrate: fix race b/w soft-offline and unpoison > > [description to be written ...] > > Signed-off-by: Naoya Horiguchi > --- > mm/migrate.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index eb4267107d1f..24f5b9acc26a 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -953,7 +953,13 @@ static ICE_noinline int unmap_and_move(new_page_t > get_new_page, > page_is_file_cache(page)); > /* Soft-offlined page shouldn't go through lru cache list */ > if (reason == MR_MEMORY_FAILURE) > - put_page(page); > + /* > + * Check race condition with unpoison, where the source > + * page is handled by unpoison handler which decrements > + * the refcount, so no need to call put_page() here. > + */ > + if (PageHWPoison(page)) > + put_page(page); > else > putback_lru_page(page); > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] target: Fix handling of small allocation lengths in REPORT LUNS
From: Roland Dreier
REPORT LUNS should not fail just because the allocation length is less
than 16. The relevant section of SPC-4 is:
4.2.5.6 Allocation length
The ALLOCATION LENGTH field specifies the maximum number of bytes or
blocks that an application client has allocated in the Data-In
Buffer. The ALLOCATION LENGTH field specifies bytes unless a
different requirement is stated in the command definition.
An allocation length of zero specifies that no data shall be
transferred. This condition shall not be considered an error.
So we should just truncate our response rather than return an error.
Signed-off-by: Roland Dreier
Signed-off-by: Spencer Baugh
---
drivers/target/target_core_spc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index da6130a..43a27bf 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -1210,17 +1210,13 @@ sense_reason_t spc_emulate_report_luns(struct se_cmd
*cmd)
struct se_dev_entry *deve;
struct se_session *sess = cmd->se_sess;
struct se_node_acl *nacl;
+ struct scsi_lun slun;
unsigned char *buf;
u32 lun_count = 0, offset = 8;
-
- if (cmd->data_length < 16) {
- pr_warn("REPORT LUNS allocation length %u too small\n",
- cmd->data_length);
- return TCM_INVALID_CDB_FIELD;
- }
+ __be32 len;
buf = transport_kmap_data_sg(cmd);
- if (!buf)
+ if (cmd->data_length && !buf)
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
/*
@@ -1241,10 +1237,12 @@ sense_reason_t spc_emulate_report_luns(struct se_cmd
*cmd)
* See SPC2-R20 7.19.
*/
lun_count++;
- if ((offset + 8) > cmd->data_length)
+ if (offset >= cmd->data_length)
continue;
- int_to_scsilun(deve->mapped_lun, (struct scsi_lun
*)[offset]);
+ int_to_scsilun(deve->mapped_lun, );
+ memcpy(buf + offset, ,
+ min(8u, cmd->data_length - offset));
offset += 8;
}
rcu_read_unlock();
@@ -1257,16 +1255,18 @@ done:
* If no LUNs are accessible, report virtual LUN 0.
*/
if (lun_count == 0) {
- int_to_scsilun(0, (struct scsi_lun *)[offset]);
+ int_to_scsilun(0, );
+ if (cmd->data_length > 8)
+ memcpy(buf + offset, ,
+ min(8u, cmd->data_length - offset));
lun_count = 1;
}
- lun_count *= 8;
- buf[0] = ((lun_count >> 24) & 0xff);
- buf[1] = ((lun_count >> 16) & 0xff);
- buf[2] = ((lun_count >> 8) & 0xff);
- buf[3] = (lun_count & 0xff);
- transport_kunmap_data_sg(cmd);
+ if (buf) {
+ len = cpu_to_be32(lun_count * 8);
+ memcpy(buf, , min_t(int, sizeof len, cmd->data_length));
+ transport_kunmap_data_sg(cmd);
+ }
target_complete_cmd_with_length(cmd, GOOD, 8 + lun_count * 8);
return 0;
--
2.5.0.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: allow sleeping when modifying store_rps_map
From: Sasha Levin
Date: Thu, 13 Aug 2015 14:03:16 -0400
> Commit 10e4ea751 ("net: Fix race condition in store_rps_map") has moved the
> manipulation of the rps_needed jump label under a spinlock. Since changing
> the state of a jump label may sleep this is incorrect and causes warnings
> during runtime.
>
> Make rps_map_lock a mutex to allow sleeping under it.
>
> Fixes: 10e4ea751 ("net: Fix race condition in store_rps_map")
> Signed-off-by: Sasha Levin
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] powerpc: Add an inline function to update POWER8 HID0
On Wed, Aug 05, 2015 at 12:38:31PM +0530, Gautham R. Shenoy wrote: > Section 3.7 of Version 1.2 of the Power8 Processor User's Manual > prescribes that updates to HID0 be preceded by a SYNC instruction and > followed by an ISYNC instruction (Page 91). > > Create an inline function name update_power8_hid0() which follows this > recipe and invoke it from the static split core path. > > Signed-off-by: Gautham R. Shenoy Hi Gautham, I've tested this on a Power 8 machine and verified that it is able to change split modes and that when doing so the new code is used. Reviewed-by: Sam Bobroff Tested-by: Sam Bobroff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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, back from holidays, found these in the cracks, one nouveau revert, one vmwgfx locking fix and a bunch of exynos fixes. Thanks, Dave. The following changes since commit 5b3e2e14eaa2a98232a4f292341fb88438685734: Merge tag 'dm-4.2-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm (2015-08-13 13:52:46 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to d211d87e14d0c1b28a60cb6b512d162634ca6a99: Revert "drm/nouveau/fifo/gk104: kick channels when deactivating them" (2015-08-14 09:50:37 +1000) Alexandre Courbot (1): Revert "drm/nouveau/fifo/gk104: kick channels when deactivating them" Andrzej Hajda (4): drm/exynos/hdmi: fix edid memory leak drm/exynos/mixer: fix interrupt clearing drm/exynos/mixer: correct vsync configuration sequence drm/exynos/mixer: always update INT_EN cache Dave Airlie (1): Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Hyungwon Hwang (1): drm/exynos: gsc: fix wrong bitwise operation for swap detection Marek Szyprowski (1): drm/exynos/fimc: fix runtime pm support Thomas Hellstrom (1): drm/vmwgfx: Fix execbuf locking issues drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 - drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++--- drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +- drivers/gpu/drm/exynos/exynos_mixer.c| 21 +++-- drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 29 +++- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++-- 6 files changed, 32 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 0/7] net: dsa: mv88e6xxx: add hardware VLAN support
From: Vivien Didelot Date: Thu, 13 Aug 2015 12:52:16 -0400 > This patchset brings support to access hardware VLAN entries in DSA and > mv88e6xxx, through switchdev VLAN objects. Looks good, series applied, thanks Vivien. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iwlwifi: out-of-bounds access in iwl_init_sband_channels
Hi,
On 08/14/2015 03:36 AM, Adrien Schildknecht wrote:
> Both loops of this function compare data from the 'chan' array and then
> check if the index is valid.
>
> The 2 conditions should be inverted to avoid an out-of-bounds access.
>
Was that found by a static analyzer or any other automated tool, or was
that the result of your very careful review?
> Signed-off-by: Adrien Schildknecht
> ---
> drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> index 21302b6..acc3d18 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
> @@ -713,12 +713,12 @@ int iwl_init_sband_channels(struct iwl_nvm_data *data,
> struct ieee80211_channel *chan = >channels[0];
> int n = 0, idx = 0;
>
> - while (chan->band != band && idx < n_channels)
> + while (idx < n_channels && chan->band != band)
> chan = >channels[++idx];
>
> sband->channels = >channels[idx];
>
> - while (chan->band == band && idx < n_channels) {
> + while (idx < n_channels && chan->band == band) {
> chan = >channels[++idx];
> n++;
> }
>
Looks fine - I'll pick it up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/decompressors: Use real out buf size for gunzip with kernel
When loading x86 64bit kernel above 4GiB with patched grub2, got kernel
gunzip error.
| early console in decompress_kernel
| decompress_kernel:
| input: [0x807f2143b4-0x807ff61aee]
| output: [0x807cc0-0x807f3ea29b] 0x027ea29c: output_len
| boot via startup_64
| KASLR using RDTSC...
| new output: [0x46fe00-0x470138cfff] 0x0338d000: output_run_size
| decompress: [0x46fe00-0x47007ea29b] <=== [0x807f2143b4-0x807ff61aee]
|
| Decompressing Linux... gz...
|
| uncompression error
|
| -- System halted
the new buffer is at 0x46fe00ULL, decompressor_gzip is using
0xffb901ff as out_len. gunzip in lib/zlib_inflate/inflate.c
cap that len to 0x01ff and decompress fails later.
We could hit this problem with crashkernel booting that uses kexec
loading kernel above 4GiB.
We have decompress_* support:
1. inbuf[]/outbuf[] for kernel preboot.
2. inbuf[]/flush() for initramfs
3. fill()/flush() for initrd.
This bug only affect kernel preboot path that use outbuf[].
Add __decompress and take real out_buf_len for gunzip instead of guessing
wrong buf size.
-v2: fix unused warning on sh/arm/m32r from Fengguang.
Signed-off-by: Yinghai Lu
Fixes: 1431574a1c4 (lib/decompressors: fix "no limit" output buffer length)
Cc: Alexandre Courbot
Cc: Jon Medhurst
Cc: Stephen Warren
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Russell King
Cc: Yoshinori Sato
Cc: Ralf Baechle
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Guan Xuetao
Cc: linux-arm-ker...@lists.infradead.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@linux-mips.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: Fengguang Wu
Cc: stable
---
arch/arm/boot/compressed/decompress.c |2 +-
arch/h8300/boot/compressed/misc.c |2 +-
arch/m32r/boot/compressed/misc.c |3 ++-
arch/mips/boot/compressed/decompress.c |4 ++--
arch/s390/boot/compressed/misc.c |2 +-
arch/sh/boot/compressed/misc.c |2 +-
arch/unicore32/boot/compressed/misc.c |4 ++--
arch/x86/boot/compressed/misc.c|3 ++-
lib/decompress_bunzip2.c |6 +++---
lib/decompress_inflate.c | 31 ++-
lib/decompress_unlz4.c |6 +++---
lib/decompress_unlzma.c|7 +++
lib/decompress_unlzo.c | 13 -
lib/decompress_unxz.c | 12 +++-
14 files changed, 70 insertions(+), 27 deletions(-)
Index: linux-2.6/arch/arm/boot/compressed/decompress.c
===
--- linux-2.6.orig/arch/arm/boot/compressed/decompress.c
+++ linux-2.6/arch/arm/boot/compressed/decompress.c
@@ -57,5 +57,5 @@ extern char * strstr(const char * s1, co
int do_decompress(u8 *input, int len, u8 *output, void (*error)(char *x))
{
- return decompress(input, len, NULL, NULL, output, NULL, error);
+ return __decompress(input, len, NULL, NULL, output, 0, NULL, error);
}
Index: linux-2.6/arch/h8300/boot/compressed/misc.c
===
--- linux-2.6.orig/arch/h8300/boot/compressed/misc.c
+++ linux-2.6/arch/h8300/boot/compressed/misc.c
@@ -70,5 +70,5 @@ void decompress_kernel(void)
free_mem_ptr = (unsigned long)&_end;
free_mem_end_ptr = free_mem_ptr + HEAP_SIZE;
- decompress(input_data, input_len, NULL, NULL, output, NULL, error);
+ __decompress(input_data, input_len, NULL, NULL, output, 0, NULL, error);
}
Index: linux-2.6/arch/m32r/boot/compressed/misc.c
===
--- linux-2.6.orig/arch/m32r/boot/compressed/misc.c
+++ linux-2.6/arch/m32r/boot/compressed/misc.c
@@ -86,6 +86,7 @@ decompress_kernel(int mmu_on, unsigned c
free_mem_end_ptr = free_mem_ptr + BOOT_HEAP_SIZE;
puts("\nDecompressing Linux... ");
- decompress(input_data, input_len, NULL, NULL, output_data, NULL, error);
+ __decompress(input_data, input_len, NULL, NULL, output_data, 0,
+ NULL, error);
puts("done.\nBooting the kernel.\n");
}
Index: linux-2.6/arch/mips/boot/compressed/decompress.c
===
--- linux-2.6.orig/arch/mips/boot/compressed/decompress.c
+++ linux-2.6/arch/mips/boot/compressed/decompress.c
@@ -111,8 +111,8 @@ void decompress_kernel(unsigned long boo
puts("\n");
/* Decompress the kernel with according algorithm */
- decompress((char *)zimage_start, zimage_size, 0, 0,
- (void *)VMLINUX_LOAD_ADDRESS_ULL, 0, error);
+ __decompress((char *)zimage_start, zimage_size, 0, 0,
+ (void *)VMLINUX_LOAD_ADDRESS_ULL, 0, 0, error);
/* FIXME: should we flush cache here? */
puts("Now, booting the kernel...\n");
Index: linux-2.6/arch/s390/boot/compressed/misc.c
Re: [PATCH] mm/hwpoison: fix race between soft_offline_page and unpoison_memory
On Thu, Aug 13, 2015 at 06:27:40PM +0800, Wanpeng Li wrote: > On 8/13/15 6:04 PM, Naoya Horiguchi wrote: > > On Thu, Aug 13, 2015 at 05:18:56PM +0800, Wanpeng Li wrote: > >> On 8/13/15 4:53 PM, Naoya Horiguchi wrote: > > ... > >>> I think that unpoison is used only in testing so this race never affects > >>> our end-users/customers, so going back to this migratetype change stuff > >>> looks unworthy to me. > >> Migratetype stuff is just removed by you two months ago, then this bug > >> occurs recently since the more and more patches which you fix some races. > > Yes, this race (which existed before my recent changes) became more visible > > IIUC, no. The page will be freed before PageHWPoison is set. So the race > doesn't exist. OK ... > > with that changes. But I don't think that simply reverting them is a right > > solution. > > > >>> If I read correctly, the old migratetype approach has a few problems: > >>> 1) it doesn't fix the problem completely, because > >>> set_migratetype_isolate() can fail to set MIGRATE_ISOLATE to the > >>> target page if the pageblock of the page contains one or more > >>> unmovable pages (i.e. has_unmovable_pages() returns true). > >>> 2) the original code changes migratetype to MIGRATE_ISOLATE forcibly, > >>> and sets it to MIGRATE_MOVABLE forcibly after soft offline, > >>> regardless > >>> of the original migratetype state, which could impact other > >>> subsystems > >>> like memory hotplug or compaction. > >> Maybe we can add a "FIXME" comment on the Migratetype stuff, since the > >> current linus tree calltrace and it should be fixed immediately, and I > >> don't see obvious bugs appear on migratetype stuffs at least currently, > >> so "FIXME" is enough. :-) > > Sorry if confusing, but my intention in saying about "FIXME" comment was > > that we can find another solution for this race rather than just reverting, > > so adding comment about the reported bug in current code (keeping code from > > 4491f712606) is OK for very short term. > > I understand that leaving a race window of BUG_ON is not the best thing, but > > as I said, this race shouldn't affect end-users, so this is not an urgent > > bug. > > # It's enough if testers know this. > > The 4.2 is coming, this patch can be applied as a temporal solution in > order to fix the broken linus tree, and the any final solution can be > figured out later. I didn't reproduce this problem yet in my environment, but from code reading I guess that checking PageHWPoison flag in unmap_and_move() like below could avoid the problem. Could you testing with this, please? Thanks, Naoya Horiguchi --- From: Naoya Horiguchi Date: Fri, 14 Aug 2015 08:04:03 +0900 Subject: [PATCH] mm: hwpoison: migrate: fix race b/w soft-offline and unpoison [description to be written ...] Signed-off-by: Naoya Horiguchi --- mm/migrate.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/migrate.c b/mm/migrate.c index eb4267107d1f..24f5b9acc26a 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -953,7 +953,13 @@ static ICE_noinline int unmap_and_move(new_page_t get_new_page, page_is_file_cache(page)); /* Soft-offlined page shouldn't go through lru cache list */ if (reason == MR_MEMORY_FAILURE) - put_page(page); + /* +* Check race condition with unpoison, where the source +* page is handled by unpoison handler which decrements +* the refcount, so no need to call put_page() here. +*/ + if (PageHWPoison(page)) + put_page(page); else putback_lru_page(page); } -- 2.4.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 1/1 V2] ipv4: off-by-one in continuation handling in /proc/net/route
From: Andy Whitcroft
Date: Thu, 13 Aug 2015 20:49:01 +0100
> When generating /proc/net/route we emit a header followed by a line for
> each route. When a short read is performed we will restart this process
> based on the open file descriptor. When calculating the start point we
> fail to take into account that the 0th entry is the header. This leads
> us to skip the first entry when doing a continuation read.
>
> This can be easily seen with the comparison below:
>
> while read l; do echo "$l"; done A
> cat /proc/net/route >B
> diff -bu A B | grep '^[+-]'
>
> On my example machine I have approximatly 10KB of route output. There we
> see the very first non-title element is lost in the while read case,
> and an entry around the 8K mark in the cat case:
>
> +wlan0 02021EAC 0003 0 0 400 0 0 0
> -tun1 00C0AC0A 0001 0 0 950 00C0 0 0 0
>
> Fix up the off-by-one when reaquiring position on continuation.
>
> Fixes: 8be33e955cb9 ("fib_trie: Fib walk rcu should take a tnode and key
> instead of a trie and a leaf")
> BugLink: http://bugs.launchpad.net/bugs/1483440
> Acked-by: Alexander Duyck
> Signed-off-by: Andy Whitcroft
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/fddi: remove HWM_REVERSE() macro
From: yalin wang Date: Thu, 13 Aug 2015 12:01:33 +0800 > HWM_REVERSE() macro is unused, remove it. > > Signed-off-by: yalin wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 29/31] parisc: handle page-less SG entries
From: James Bottomley Date: Thu, 13 Aug 2015 20:59:20 -0700 > On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote: >> On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote: >> > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote: >> >> I'm assuming that anybody who wants to use the page-less >> >> scatter-gather lists always does so on memory that isn't actually >> >> virtually mapped at all, or only does so on sane architectures that >> >> are cache coherent at a physical level, but I'd like that assumption >> >> *documented* somewhere. >> > >> > It's temporarily mapped by kmap-like helpers. That code isn't in >> > this series. The most recent version of it is here: >> > >> > https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/commit/?h=pfn=de8237c99fdb4352be2193f3a7610e902b9bb2f0 >> > >> > note that it's not doing the cache flushing it would have to do yet, but >> > it's also only enabled for x86 at the moment. >> >> For virtually tagged caches I assume we would temporarily map with >> kmap_atomic_pfn_t(), similar to how drm_clflush_pages() implements >> powerpc support. However with DAX we could end up with multiple >> virtual aliases for a page-less pfn. > > At least on some PA architectures, you have to be very careful. > Improperly managed, multiple aliases will cause the system to crash > (actually a machine check in the cache chequerboard). For the most > temperamental systems, we need the cache line flushed and the alias > mapping ejected from the TLB cache before we access the same page at an > inequivalent alias. Also, I want to mention that on sparc64 we manage the cache aliasing state in the page struct. Until a page is mapped into userspace, we just record the most recent cpu to store into that page with kernel side mappings. Once the page ends up being mapped or the cpu doing kernel side stores changes, we actually perform the cache flush. Generally speaking, I think that all actual physical memory the kernel operates on should have a struct page backing it. So this whole discussion of operating on physical memory in scatter lists without backing page structs feels really foreign to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] security/smack/smack_lsm.c: Fix build error when CONFIG_SECURITY_SMACK_BRINGUP is not defined
On 8/13/2015 5:52 PM, Murilo Opsfelder Araujo wrote:
> This change fixes the following build error when
> CONFIG_SECURITY_SMACK_BRINGUP is not defined:
>
> security/smack/smack_lsm.c: In function ‘smack_parse_opts_str’:
> security/smack/smack_lsm.c:618:26: error: ‘tokens’ undeclared (first use in
> this function)
>token = match_token(p, tokens, args);
> ^
> security/smack/smack_lsm.c:618:26: note: each undeclared identifier is
> reported only once for each function it appears in
>
> The above has been introduced by commit
> 3bf2789cad9e6573dc19a6c3d123c2c049f2d90f "smack: allow mount opts setting
> over filesystems with binary mount data".
>
> Signed-off-by: Murilo Opsfelder Araujo
I have already made a pull request for an almost identical patch
to James' next tree.
> ---
> security/smack/smack_lsm.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 54fb3a1..6201907 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -57,14 +57,6 @@ LIST_HEAD(smk_ipv6_port_list);
> static struct kmem_cache *smack_inode_cache;
> int smack_enabled;
>
> -#ifdef CONFIG_SECURITY_SMACK_BRINGUP
> -static char *smk_bu_mess[] = {
> - "Bringup Error",/* Unused */
> - "Bringup", /* SMACK_BRINGUP_ALLOW */
> - "Unconfined Subject", /* SMACK_UNCONFINED_SUBJECT */
> - "Unconfined Object",/* SMACK_UNCONFINED_OBJECT */
> -};
> -
> static const match_table_t tokens = {
> {Opt_fsdefault, SMK_FSDEFAULT "%s"},
> {Opt_fsfloor, SMK_FSFLOOR "%s"},
> @@ -74,6 +66,14 @@ static const match_table_t tokens = {
> {Opt_error, NULL},
> };
>
> +#ifdef CONFIG_SECURITY_SMACK_BRINGUP
> +static char *smk_bu_mess[] = {
> + "Bringup Error",/* Unused */
> + "Bringup", /* SMACK_BRINGUP_ALLOW */
> + "Unconfined Subject", /* SMACK_UNCONFINED_SUBJECT */
> + "Unconfined Object",/* SMACK_UNCONFINED_OBJECT */
> +};
> +
> static void smk_bu_mode(int mode, char *s)
> {
> int i = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/9] Fixes and new clocks support for Mediatek MT8173
On Tue, Aug 11, 2015 at 12:43 PM, Daniel Kurtz wrote: > Hi James, > > On Mon, Aug 10, 2015 at 5:50 PM, James Liao wrote: >> This patchset is based on 4.2-rc2 and [1], and contains minor fixes and >> subsystem clocks support for Mediatek MT8173. >> >> The previous reviews can be found in [2]. >> >> changes since v6: >> - Use DUMMY_RATE (0) instead of typical rate for clocks that we don't care >> and not controlled in CCF. > > For the whole series: > Reviewed-by: Daniel Kurtz Hi Sascha, Are you happy with these patches now? Thanks, -Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 29/31] parisc: handle page-less SG entries
On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote: > On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote: > > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote: > >> I'm assuming that anybody who wants to use the page-less > >> scatter-gather lists always does so on memory that isn't actually > >> virtually mapped at all, or only does so on sane architectures that > >> are cache coherent at a physical level, but I'd like that assumption > >> *documented* somewhere. > > > > It's temporarily mapped by kmap-like helpers. That code isn't in > > this series. The most recent version of it is here: > > > > https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/commit/?h=pfn=de8237c99fdb4352be2193f3a7610e902b9bb2f0 > > > > note that it's not doing the cache flushing it would have to do yet, but > > it's also only enabled for x86 at the moment. > > For virtually tagged caches I assume we would temporarily map with > kmap_atomic_pfn_t(), similar to how drm_clflush_pages() implements > powerpc support. However with DAX we could end up with multiple > virtual aliases for a page-less pfn. At least on some PA architectures, you have to be very careful. Improperly managed, multiple aliases will cause the system to crash (actually a machine check in the cache chequerboard). For the most temperamental systems, we need the cache line flushed and the alias mapping ejected from the TLB cache before we access the same page at an inequivalent alias. 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/
linux-next: manual merge of the xen-tip tree with Linus' tree
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/Makefile
between commit:
fc5fee86bdd3 ("x86/xen: build "Xen PV" APIC driver for domU as well")
from Linus' tree and commit:
6e3012fba294 ("xen/PMU: Initialization code for Xen PMU")
from the xen-tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/xen/Makefile
index 4b6e29ac0968,071fab5c720e..
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@@ -13,7 -13,7 +13,7 @@@ CFLAGS_mmu.o := $(nostackp
obj-y := enlighten.o setup.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
grant-table.o suspend.o platform-pci-unplug.o \
- p2m.o apic.o
- p2m.o pmu.o
++ p2m.o apic.o pmu.o
obj-$(CONFIG_EVENT_TRACING) += trace.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Revert "drm/nouveau/fifo/gk104: kick channels when deactivating them"
On Wed, Aug 12, 2015 at 6:59 PM, Afzal Mohammed wrote: > Hi, > > On Wed, Aug 12, 2015 at 04:40:57PM +0900, Alexandre Courbot wrote: > >> Great, thanks. Are you also on an optimus configuration with the >> NVIDIA card being the secondary GPU? > > Spec says graphic processor is NVIDIA GeForce NV14P-GV2 GT40M, system > is Lenovo E431 laptop. > > I am a stranger here, started Kernel journey towards north and reached > south since the system wasn't booting :), don't know how to find it is > an optimus configuration, if above details aren't enough, let me know > how to find out. Thanks for the details! An optimus configuration means that display and basic acceleration is provided by an integrated Intel graphics, and the NVIDIA GPU can be switched on/off dynamically to provide more power when needed. According to your laptop reference, this seems to be the kind of configuration you have. It is relevant because this issue seems to happen when the NVIDIA GPU is switched off during boot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] Documentation: DT: FTM: add FTM0 be used as alarm timer
Thank Yoder,
Fix them in next version.
Regards,
-Dongsheng
> -Original Message-
> From: Stuart Yoder [mailto:b08...@gmail.com]
> Sent: Friday, August 14, 2015 12:23 AM
> To: Wang Dongsheng-B40534
> Cc: shawn@linaro.org; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965
> Subject: Re: [PATCH v3 1/2] Documentation: DT: FTM: add FTM0 be used as alarm
> timer
>
> On Tue, Aug 11, 2015 at 11:01 PM, Dongsheng Wang
> wrote:
> > From: Wang Dongsheng
> >
> > In freescale layerscape platform there is only FTM0 can be used as
> > alarm timer to wake up system. So add FTM0 description for devicetree
> > document.
>
> Suggestion:
>
> In the Freescale Layerscape platform a flextimer module can be used
> as an alarm timer to wake up the system. Define a binding for this
> alarm.
>
> > Signed-off-by: Wang Dongsheng
> > ---
> > V3:
> > Include this patch in V3.
> >
> > diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> > index aa8c402..380a0b3d 100644
> > --- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> > +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> > @@ -1,5 +1,7 @@
> > Freescale FlexTimer Module (FTM) Timer
> >
> > +* Default FTM Timer
> > +
> > Required properties:
> >
> > - compatible : should be "fsl,ftm-timer"
> > @@ -29,3 +31,26 @@ ftm: ftm@400b8000 {
> > < VF610_CLK_FTM3_EXT_FIX_EN>;
> > big-endian;
> > };
> > +
> > +* FTM Alarm Timer
> > + The default FTM device contains eight FlexTimer modules. FlexTimer1 is in
> > + on-domain(power is not switched off in deep sleep mode). Other seven
> FlexTimer
> > + modules(flextimer2/3/4/5/6/7/8) are in off-domain (power is switched off
> > in
> > + deep sleep mode).
>
> Suggestion:
>
> This binding describes a Flextimer (FTM) instance that can be used as an
> alarm
> to wake up a system in deep sleep. The flextimer module with alarm
> support is in a power domain that remains awake when the SoC is in
> deep sleep mode.
>
> (don't use flextimer1 in the binding...for all you know in the next SoC it
> will be flextimer7 that has this capability)
>
> > +Required properties:
> > +
> > +- compatible : should be "fsl,ftm-alarm".
> > +- reg : should contain base address and length of FTM timer 0 register.
>
> "should contain the address and size of the FTM alarm module registers"
>
> (don't use the number 0)
>
> > +- interrupts : Should contain FTM 0 interrupt.
>
>"describes the FTM alarm interrupt"
>
> > +- big-endian: One boolean property, the big endian mode will be in use if
> > it
> is
> > + present, or the little endian mode will be in use for all the device
> registers.
> > +
> > +Example:
> > +ftm0: ftm0@29d {
> > + compatible = "fsl,ftm-alarm";
> > + reg = <0x0 0x29d 0x0 0x1>;
> > + interrupts = ;
> > + big-endian;
> > + status = "disabled";
> > +};
>
> Drop the number 0 from the names in your example.
>
> Thanks,
> Stuart
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 29/31] parisc: handle page-less SG entries
On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote: > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote: >> I'm assuming that anybody who wants to use the page-less >> scatter-gather lists always does so on memory that isn't actually >> virtually mapped at all, or only does so on sane architectures that >> are cache coherent at a physical level, but I'd like that assumption >> *documented* somewhere. > > It's temporarily mapped by kmap-like helpers. That code isn't in > this series. The most recent version of it is here: > > https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/commit/?h=pfn=de8237c99fdb4352be2193f3a7610e902b9bb2f0 > > note that it's not doing the cache flushing it would have to do yet, but > it's also only enabled for x86 at the moment. For virtually tagged caches I assume we would temporarily map with kmap_atomic_pfn_t(), similar to how drm_clflush_pages() implements powerpc support. However with DAX we could end up with multiple virtual aliases for a page-less pfn. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] usb: dwc2: reset AHB hclk domain before init
在 2015/8/14 8:09, John Youn 写道: On 8/11/2015 12:57 AM, Yunzhi Li wrote: We initiate dwc2 usb controller in BIOS, when kernel driver start-up we should reset AHB hclk domain to reset all AHB interface registers to default. Without this the FIFO value setting might be incorrect because calculating FIFO size need the power-on value of GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers. This patch could avoid warnning massage like in rk3288 platform: [2.074764] dwc2 ff58.usb: 256 invalid for host_perio_tx_fifo_size. Check HW configuration. .. I didn't receive the other two patches in this series so I was confused about where the "ahb_reset" was coming from when I replied to your other patch. I see you changed the name and documented the DT so never mind. Another thing is that there probably shouldn't be a debug message on the IS_ERR condition since that is the common case and of no interest to other platforms. The other two resets you added aren't used by the driver anywhere right? Maybe those should be left out until they are. John Hi John , Here is the other two patches : https://patchwork.kernel.org/patch/6989541/ https://patchwork.kernel.org/patch/6989531/ ahb_reset is hreset_n signal of dwc2 IP. Our rk3288 SoC implement connect this signal to a special register in clock ang reset unit (CRU) module, set this register will reset dwc2 control and status registers(CSR) to default value. You could find more info in> 4.4.1 System Clock and Reset Signals. Our problem is that dwc2_get_hwparams() reads fifo size registers and reguards it as the power-on reset value, then dwc2_set_param_host_perio_tx_fifo_size() will check this value and make sure the new fifo size value is no bigger than the power-on reset value. But we init and set these fifo registers in BIOS, so here hw->xxx_fifo_size is not the real power-on reset vaule. So we hope to reset CSR before dwc2_get_hwparams(). I have another ideal: we might use GRSTCTL.CSftRst instead of hreset_n to reset dwc2 CSR. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 02/20] x86/asm: Add C versions of frame pointer macros
Add C versions of the frame pointer macros which can be used to create a stack frame in inline assembly. Signed-off-by: Josh Poimboeuf --- arch/x86/include/asm/frame.h | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/frame.h b/arch/x86/include/asm/frame.h index 8a6cd26..9a30ec7 100644 --- a/arch/x86/include/asm/frame.h +++ b/arch/x86/include/asm/frame.h @@ -1,10 +1,10 @@ #ifndef _ASM_X86_FRAME_H #define _ASM_X86_FRAME_H -#ifdef __ASSEMBLY__ - #include +#ifdef __ASSEMBLY__ + /* * These are stack frame creation macros. They should be used by every * callable non-leaf asm function to make kernel stack traces more reliable. @@ -22,5 +22,21 @@ #endif .endm +#else /* !__ASSEMBLY__ */ + +#ifdef CONFIG_FRAME_POINTER + +#define FRAME_BEGIN\ + "push %" _ASM_BP "\n" \ + _ASM_MOV "%" _ASM_SP ", %" _ASM_BP "\n" + +#define FRAME_END "pop %" _ASM_BP "\n" + +#else /* !CONFIG_FRAME_POINTER */ + +#define FRAME_BEGIN "" +#define FRAME_END "" + +#endif /* CONFIG_FRAME_POINTER */ #endif /* __ASSEMBLY__ */ #endif /* _ASM_X86_FRAME_H */ -- 2.4.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 v10 04/20] x86/stackvalidate: Add file and directory ignores
Tell stackvalidate to skip validation of the following code: - boot image - vdso image - kexec purgatory - realmode - efi libstub - scripts/mod They all run outside the kernel's normal mode of operation and they don't affect runtime kernel stack traces, so they're free to skirt the stackvalidate rules. Signed-off-by: Josh Poimboeuf --- arch/x86/boot/Makefile| 3 ++- arch/x86/boot/compressed/Makefile | 3 ++- arch/x86/entry/vdso/Makefile | 5 - arch/x86/purgatory/Makefile | 2 ++ arch/x86/realmode/Makefile| 4 +++- arch/x86/realmode/rm/Makefile | 3 ++- drivers/firmware/efi/libstub/Makefile | 1 + scripts/mod/Makefile | 2 ++ 8 files changed, 18 insertions(+), 5 deletions(-) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index 0d553e5..d31808c 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -14,7 +14,8 @@ # Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode. # The number is the same as you would ordinarily press at bootup. -KASAN_SANITIZE := n +KASAN_SANITIZE := n +STACKVALIDATE := n SVGA_MODE := -DSVGA_MODE=NORMAL_VGA diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile index 0a291cd..530a46f 100644 --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -16,7 +16,8 @@ # (see scripts/Makefile.lib size_append) # compressed vmlinux.bin.all + u32 size of vmlinux.bin.all -KASAN_SANITIZE := n +KASAN_SANITIZE := n +STACKVALIDATE := n targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \ vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4 diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index a3d0767..b7cbf61 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -3,7 +3,9 @@ # KBUILD_CFLAGS += $(DISABLE_LTO) -KASAN_SANITIZE := n + +KASAN_SANITIZE := n +STACKVALIDATE := n VDSO64-$(CONFIG_X86_64):= y VDSOX32-$(CONFIG_X86_X32_ABI) := y @@ -15,6 +17,7 @@ vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o # files to link into kernel obj-y += vma.o +STACKVALIDATE_vma.o:= y # vDSO images to build vdso_img-$(VDSO64-y) += 64 diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile index 2c835e3..a736c19 100644 --- a/arch/x86/purgatory/Makefile +++ b/arch/x86/purgatory/Makefile @@ -1,3 +1,5 @@ +STACKVALIDATE := n + purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o string.o targets += $(purgatory-y) diff --git a/arch/x86/realmode/Makefile b/arch/x86/realmode/Makefile index e02c2c6..7a2d4df 100644 --- a/arch/x86/realmode/Makefile +++ b/arch/x86/realmode/Makefile @@ -6,7 +6,9 @@ # for more details. # # -KASAN_SANITIZE := n +KASAN_SANITIZE := n +STACKVALIDATE := n + subdir- := rm obj-y += init.o diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile index 2730d77..d462a57 100644 --- a/arch/x86/realmode/rm/Makefile +++ b/arch/x86/realmode/rm/Makefile @@ -6,7 +6,8 @@ # for more details. # # -KASAN_SANITIZE := n +KASAN_SANITIZE := n +STACKVALIDATE := n always := realmode.bin realmode.relocs diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index 816dbe9..b392f3f 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -20,6 +20,7 @@ KBUILD_CFLAGS := $(cflags-y) \ GCOV_PROFILE := n KASAN_SANITIZE := n +STACKVALIDATE := n lib-y := efi-stub-helper.o lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile index c11212f..374c413 100644 --- a/scripts/mod/Makefile +++ b/scripts/mod/Makefile @@ -1,3 +1,5 @@ +STACKVALIDATE := n + hostprogs-y:= modpost mk_elfconfig always := $(hostprogs-y) empty.o -- 2.4.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 v10 00/20] Compile-time stack validation
This is v10 of the compile-time stack validation patch set, along with proposed fixes for many of the warnings it found. It's based on the tip/master branch. The frame pointer macros have been renamed from FRAME/ENDFRAME to FRAME_BEGIN/FRAME_END. v9 can be found here: https://lkml.kernel.org/r/cover.1438963009.git.jpoim...@redhat.com For more information about the motivation behind this patch set, and more details about what it does, please see the changelog in patch 3. Patches 1-5 are the stackvalidate tool and some related macros. Patches 6-20 are some proposed fixes for several of the warnings reported by stackvalidate. They've been compile-tested and boot tested in a VM, but I haven't attempted any meaningful testing for many of them. v10: - add scripts/mod to directory ignores - remove circular dependencies for ignored objects which are built before stackvalidate - fix CONFIG_MODVERSIONS incompatibility v9: - rename FRAME/ENDFRAME -> FRAME_BEGIN/FRAME_END - fix jump table issue for when the original instruction is a jump - drop paravirt thunk alignment patch - add maintainers to CC for proposed warning fixes v8: - add proposed fixes for warnings - fix all memory leaks - process ignores earlier and add more ignore checks - always assume POPCNT alternative is enabled - drop hweight inline asm fix - drop __schedule() ignore patch - change .Ltemp_\@ to .Lstackvalidate_ignore_\@ in asm macro - fix CONFIG_* checks in asm macros - add C versions of ignore macros and frame macros - change ";" to "\n" in C macros - add ifdef CONFIG_STACK_VALIDATION checks in C ignore macros - use numbered label in C ignore macro - add missing break in switch case statement in arch-x86.c v7: - sibling call support - document proposed solution for inline asm() frame pointer issues - say "kernel entry/exit" instead of "context switch" - clarify the checking of switch statement jump tables - discard __stackvalidate_ignore_* sections in linker script - use .Ltemp_\@ to get a unique label instead of static 3-digit number - change STACKVALIDATE_IGNORE_FUNC variable to a static - move STACKVALIDATE_IGNORE_INSN to arch-specific .h file v6: - rename asmvalidate -> stackvalidate (again) - gcc-generated object file support - recursive branch state analysis - external jump support - fixup/exception table support - jump label support - switch statement jump table support - added documentation - detection of "noreturn" dead end functions - added a Kbuild mechanism for skipping files and dirs - moved frame pointer macros to arch/x86/include/asm/frame.h - moved ignore macros to include/linux/stackvalidate.h v5: - stackvalidate -> asmvalidate - frame pointers only required for non-leaf functions - check for the use of the FP_SAVE/RESTORE macros instead of manually analyzing code to detect frame pointer usage - additional checks to ensure each function doesn't leave its boundaries - make the macros simpler and more flexible - support for analyzing ALTERNATIVE macros - simplified the arch interfaces in scripts/asmvalidate/arch.h - fixed some asmvalidate warnings - rebased onto latest tip asm cleanups - many more small changes v4: - Changed the default to CONFIG_STACK_VALIDATION=n, until all the asm code can get cleaned up. - Fixed a stackvalidate error path exit code issue found by Michal Marek. v3: - Added a patch to make the push/pop CFI macros arch-independent, as suggested by H. Peter Anvin v2: - Fixed memory leaks reported by Petr Mladek Cc: linux-kernel@vger.kernel.org Cc: Michal Marek Cc: Peter Zijlstra Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Andi Kleen Cc: Pedro Alves Cc: Namhyung Kim Cc: Bernd Petrovitsch Cc: "Chris J Arges" Cc: live-patch...@vger.kernel.org Josh Poimboeuf (20): x86/asm: Frame pointer macro cleanup x86/asm: Add C versions of frame pointer macros x86/stackvalidate: Compile-time stack validation x86/stackvalidate: Add file and directory ignores x86/stackvalidate: Add ignore macros x86/xen: Add stack frame dependency to hypercall inline asm calls x86/paravirt: Add stack frame dependency to PVOP inline asm calls x86/paravirt: Create a stack frame in PV_CALLEE_SAVE_REGS_THUNK x86/amd: Set ELF function type for vide() x86/reboot: Add ljmp instructions to stackvalidate whitelist x86/xen: Add xen_cpuid() and xen_setup_gdt() to stackvalidate whitelists x86/asm/crypto: Create stack frames in aesni-intel_asm.S x86/asm/crypto: Move .Lbswap_mask data to .rodata section x86/asm/crypto: Move jump_table to .rodata section x86/asm/crypto: Create stack frames in clmul_ghash_mul/update() x86/asm/entry: Create stack frames in thunk functions x86/asm/acpi: Create a stack frame in do_suspend_lowlevel() x86/asm: Create stack frames in rwsem functions x86/asm/efi: Create a stack frame in efi_call() x86/asm/power: Create stack frames in hibernate_asm_64.S Documentation/stack-validation.txt| 193 ++ MAINTAINERS
[PATCH v10 03/20] x86/stackvalidate: Compile-time stack validation
This adds a CONFIG_STACK_VALIDATION option which enables a host tool named stackvalidate which runs at compile time. It analyzes every .o file and ensures the validity of its stack metadata. It enforces a set of rules on asm code and C inline assembly code so that stack traces can be reliable. Currently it checks frame pointer usage. I also plan to add DWARF CFI validation for C .o files and CFI generation for asm .o files. For each function, it recursively follows all possible code paths and validates the correct frame pointer state at each instruction. It also follows code paths involving special sections, like .altinstructions, __jump_table, and __ex_table, which can add alternative execution paths to a given instruction (or set of instructions). Similarly, it knows how to follow switch statements, for which gcc sometimes uses jump tables. To achieve the validation, stackvalidate enforces the following rules: 1. Each callable function must be annotated as such with the ELF function type. In asm code, this is typically done using the ENTRY/ENDPROC macros. If stackvalidate finds a return instruction outside of a function, it flags an error since that usually indicates callable code which should be annotated accordingly. 2. Conversely, each section of code which is *not* callable should *not* be annotated as an ELF function. The ENDPROC macro shouldn't be used in this case. 3. Each callable function which calls another function must have the correct frame pointer logic, if required by CONFIG_FRAME_POINTER or the architecture's back chain rules. This can by done in asm code with the FRAME_BEGIN/FRAME_END macros. 4. Dynamic jumps and jumps to undefined symbols are only allowed if: a) the jump is part of a switch statement; or b) the jump matches sibling call semantics and the frame pointer has the same value it had on function entry. 5. A callable function may not execute kernel entry/exit instructions. The only code which needs such instructions is kernel entry code, which shouldn't be in callable functions anyway. It currently only supports x86_64. I tried to make the code generic so that support for other architectures can hopefully be plugged in relatively easily. As a first step, CONFIG_STACK_VALIDATION is disabled by default, and all reported non-compliances result in warnings. Once we get them all cleaned up, we can change the default to CONFIG_STACK_VALIDATION=y and change the warnings to errors to keep the stack metadata clean. On my Lenovo laptop with a i7-4810MQ 4-core/8-thread CPU, building the kernel with it enabled adds less than 3 seconds of total build time. It hasn't been optimized for performance yet, so there are probably some opportunities for better build performance. Signed-off-by: Josh Poimboeuf --- Documentation/stack-validation.txt| 193 +++ MAINTAINERS | 8 + arch/Kconfig | 6 + arch/x86/Kconfig | 1 + arch/x86/Makefile | 6 +- lib/Kconfig.debug | 11 + scripts/Makefile | 1 + scripts/Makefile.build| 37 +- scripts/stackvalidate/Makefile| 24 + scripts/stackvalidate/arch-x86.c | 160 ++ scripts/stackvalidate/arch.h | 44 ++ scripts/stackvalidate/elf.c | 427 +++ scripts/stackvalidate/elf.h | 92 scripts/stackvalidate/list.h | 217 scripts/stackvalidate/special.c | 199 +++ scripts/stackvalidate/special.h | 42 ++ scripts/stackvalidate/stackvalidate.c | 976 ++ 17 files changed, 2439 insertions(+), 5 deletions(-) create mode 100644 Documentation/stack-validation.txt create mode 100644 scripts/stackvalidate/Makefile create mode 100644 scripts/stackvalidate/arch-x86.c create mode 100644 scripts/stackvalidate/arch.h create mode 100644 scripts/stackvalidate/elf.c create mode 100644 scripts/stackvalidate/elf.h create mode 100644 scripts/stackvalidate/list.h create mode 100644 scripts/stackvalidate/special.c create mode 100644 scripts/stackvalidate/special.h create mode 100644 scripts/stackvalidate/stackvalidate.c diff --git a/Documentation/stack-validation.txt b/Documentation/stack-validation.txt new file mode 100644 index 000..c3d3d35 --- /dev/null +++ b/Documentation/stack-validation.txt @@ -0,0 +1,193 @@ +Compile-time stack validation += + + +Overview + + +The CONFIG_STACK_VALIDATION option enables a host tool named +stackvalidate which runs at compile time. It analyzes every .o file and +ensures the validity of its stack metadata. It enforces a set of rules +on asm code and C inline assembly code so that stack traces can be +reliable. + +Currently it only checks frame pointer usage, but there are plans to add +CFI validation for C files and CFI generation for asm
[PATCH v10 05/20] x86/stackvalidate: Add ignore macros
Add new stackvalidate ignore macros: STACKVALIDATE_IGNORE_INSN and
STACKVALIDATE_IGNORE_FUNC. These can be used to tell stackvalidate to
skip validation of an instruction or a function, respectively.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stackvalidate.h | 45
arch/x86/kernel/vmlinux.lds.S| 5 +++-
include/linux/stackvalidate.h| 28 ++
3 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/include/asm/stackvalidate.h
create mode 100644 include/linux/stackvalidate.h
diff --git a/arch/x86/include/asm/stackvalidate.h
b/arch/x86/include/asm/stackvalidate.h
new file mode 100644
index 000..95db052
--- /dev/null
+++ b/arch/x86/include/asm/stackvalidate.h
@@ -0,0 +1,45 @@
+#ifndef _ASM_X86_STACKVALIDATE_H
+#define _ASM_X86_STACKVALIDATE_H
+
+#include
+
+#ifdef __ASSEMBLY__
+
+/*
+ * This asm macro tells the stack validation script to ignore the instruction
+ * immediately after the macro. It should only be used in special cases where
+ * you're 100% sure it won't affect the reliability of frame pointers and
+ * kernel stack traces.
+ *
+ * For more information, see Documentation/stack-validation.txt.
+ */
+.macro STACKVALIDATE_IGNORE_INSN
+#ifdef CONFIG_STACK_VALIDATION
+ .Lstackvalidate_ignore_\@:
+ .pushsection __stackvalidate_ignore_insn, "a"
+ _ASM_ALIGN
+ .long .Lstackvalidate_ignore_\@ - .
+ .popsection
+#endif
+.endm
+
+#else /* !__ASSEMBLY__ */
+
+#ifdef CONFIG_STACK_VALIDATION
+
+#define STACKVALIDATE_IGNORE_INSN \
+ "1:\n" \
+ ".pushsection __stackvalidate_ignore_insn, \"a\"\n" \
+ _ASM_ALIGN "\n" \
+ ".long 1b - .\n"\
+ ".popsection\n"
+
+#else /* !CONFIG_STACK_VALIDATION */
+
+#define STACKVALIDATE_IGNORE_INSN ""
+
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _ASM_X86_STACKVALIDATE_H */
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 00bf300..f2f8d7a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -332,7 +332,10 @@ SECTIONS
/* Sections to be discarded */
DISCARDS
- /DISCARD/ : { *(.eh_frame) }
+ /DISCARD/ : {
+ *(.eh_frame)
+ *(__stackvalidate_ignore_*)
+ }
}
diff --git a/include/linux/stackvalidate.h b/include/linux/stackvalidate.h
new file mode 100644
index 000..4ae242c
--- /dev/null
+++ b/include/linux/stackvalidate.h
@@ -0,0 +1,28 @@
+#ifndef _LINUX_STACKVALIDATE_H
+#define _LINUX_STACKVALIDATE_H
+
+#include
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_STACK_VALIDATION
+/*
+ * This C macro tells the stack validation script to ignore the function. It
+ * should only be used in special cases where you're 100% sure it won't affect
+ * the reliability of frame pointers and kernel stack traces.
+ *
+ * For more information, see Documentation/stack-validation.txt.
+ */
+#define STACKVALIDATE_IGNORE_FUNC(_func) \
+ static void __used __section(__stackvalidate_ignore_func) \
+ *__stackvalidate_ignore_func_##_func = _func
+
+#else /* !CONFIG_STACK_VALIDATION */
+
+#define STACKVALIDATE_IGNORE_FUNC(_func)
+
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _LINUX_STACKVALIDATE_H */
--
2.4.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 v10 07/20] x86/paravirt: Add stack frame dependency to PVOP inline asm calls
If a PVOP call macro is inlined at the beginning of a function, gcc can
insert the call instruction before setting up a stack frame, which
breaks frame pointer convention if CONFIG_FRAME_POINTER is enabled and
can result in a bad stack trace.
Force a stack frame to be created if CONFIG_FRAME_POINTER is enabled by
listing the stack pointer as an output operand for the PVOP inline asm
statements.
Signed-off-by: Josh Poimboeuf
Cc: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Alok Kataria
Cc: Rusty Russell
---
arch/x86/include/asm/paravirt_types.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index ce029e4..1812294 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -497,8 +497,9 @@ int paravirt_disable_iospace(void);
* makes sure the incoming and outgoing types are always correct.
*/
#ifdef CONFIG_X86_32
-#define PVOP_VCALL_ARGS\
- unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx
+#define PVOP_VCALL_ARGS
\
+ unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx; \
+ register void *__sp asm("esp")
#define PVOP_CALL_ARGS PVOP_VCALL_ARGS
#define PVOP_CALL_ARG1(x) "a" ((unsigned long)(x))
@@ -516,9 +517,10 @@ int paravirt_disable_iospace(void);
#define VEXTRA_CLOBBERS
#else /* CONFIG_X86_64 */
/* [re]ax isn't an arg, but the return val */
-#define PVOP_VCALL_ARGS\
- unsigned long __edi = __edi, __esi = __esi, \
- __edx = __edx, __ecx = __ecx, __eax = __eax
+#define PVOP_VCALL_ARGS\
+ unsigned long __edi = __edi, __esi = __esi, \
+ __edx = __edx, __ecx = __ecx, __eax = __eax;\
+ register void *__sp asm("rsp")
#define PVOP_CALL_ARGS PVOP_VCALL_ARGS
#define PVOP_CALL_ARG1(x) "D" ((unsigned long)(x))
@@ -557,7 +559,7 @@ int paravirt_disable_iospace(void);
asm volatile(pre\
paravirt_alt(PARAVIRT_CALL)\
post \
-: call_clbr\
+: "+r" (__sp), call_clbr \
: paravirt_type(op), \
paravirt_clobber(clbr), \
##__VA_ARGS__\
@@ -567,7 +569,7 @@ int paravirt_disable_iospace(void);
asm volatile(pre\
paravirt_alt(PARAVIRT_CALL)\
post \
-: call_clbr\
+: "+r" (__sp), call_clbr \
: paravirt_type(op), \
paravirt_clobber(clbr), \
##__VA_ARGS__\
@@ -594,7 +596,7 @@ int paravirt_disable_iospace(void);
asm volatile(pre\
paravirt_alt(PARAVIRT_CALL)\
post \
-: call_clbr\
+: "+r" (__sp), call_clbr \
: paravirt_type(op), \
paravirt_clobber(clbr), \
##__VA_ARGS__\
--
2.4.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 v10 08/20] x86/paravirt: Create a stack frame in PV_CALLEE_SAVE_REGS_THUNK
A function created with the PV_CALLEE_SAVE_REGS_THUNK macro doesn't set
up a new stack frame before the call instruction, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace. Also, the thunk functions aren't annotated as ELF
callable functions.
Create a stack frame when CONFIG_FRAME_POINTER is enabled and add the
ELF function type.
Signed-off-by: Josh Poimboeuf
Cc: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Alok Kataria
Cc: Rusty Russell
---
arch/x86/include/asm/paravirt.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index c2be037..0d28801 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
static inline int paravirt_enabled(void)
{
@@ -772,15 +773,19 @@ static __always_inline void __ticket_unlock_kick(struct
arch_spinlock *lock,
* call. The return value in rax/eax will not be saved, even for void
* functions.
*/
+#define PV_THUNK_NAME(func) "__raw_callee_save_" #func
#define PV_CALLEE_SAVE_REGS_THUNK(func)
\
extern typeof(func) __raw_callee_save_##func; \
\
asm(".pushsection .text;" \
- ".globl __raw_callee_save_" #func " ; " \
- "__raw_callee_save_" #func ": " \
+ ".globl " PV_THUNK_NAME(func) ";" \
+ ".type " PV_THUNK_NAME(func) ", @function;" \
+ PV_THUNK_NAME(func) ":" \
+ FRAME_BEGIN \
PV_SAVE_ALL_CALLER_REGS \
"call " #func ";" \
PV_RESTORE_ALL_CALLER_REGS \
+ FRAME_END \
"ret;" \
".popsection")
--
2.4.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 v10 12/20] x86/asm/crypto: Create stack frames in aesni-intel_asm.S
aesni-intel_asm.S has several callable non-leaf functions which don't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create stack frames for them when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf Cc: Herbert Xu Cc: "David S. Miller" --- arch/x86/crypto/aesni-intel_asm.S | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 6bd2c6c..289ef12 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -31,6 +31,7 @@ #include #include +#include /* * The following macros are used to move an (un)aligned 16 byte value to/from @@ -1800,6 +1801,7 @@ ENDPROC(_key_expansion_256b) * unsigned int key_len) */ ENTRY(aesni_set_key) + FRAME_BEGIN #ifndef __x86_64__ pushl KEYP movl 8(%esp), KEYP # ctx @@ -1905,6 +1907,7 @@ ENTRY(aesni_set_key) #ifndef __x86_64__ popl KEYP #endif + FRAME_END ret ENDPROC(aesni_set_key) @@ -1912,6 +1915,7 @@ ENDPROC(aesni_set_key) * void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src) */ ENTRY(aesni_enc) + FRAME_BEGIN #ifndef __x86_64__ pushl KEYP pushl KLEN @@ -1927,6 +1931,7 @@ ENTRY(aesni_enc) popl KLEN popl KEYP #endif + FRAME_END ret ENDPROC(aesni_enc) @@ -2101,6 +2106,7 @@ ENDPROC(_aesni_enc4) * void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src) */ ENTRY(aesni_dec) + FRAME_BEGIN #ifndef __x86_64__ pushl KEYP pushl KLEN @@ -2117,6 +2123,7 @@ ENTRY(aesni_dec) popl KLEN popl KEYP #endif + FRAME_END ret ENDPROC(aesni_dec) @@ -2292,6 +2299,7 @@ ENDPROC(_aesni_dec4) * size_t len) */ ENTRY(aesni_ecb_enc) + FRAME_BEGIN #ifndef __x86_64__ pushl LEN pushl KEYP @@ -2342,6 +2350,7 @@ ENTRY(aesni_ecb_enc) popl KEYP popl LEN #endif + FRAME_END ret ENDPROC(aesni_ecb_enc) @@ -2350,6 +2359,7 @@ ENDPROC(aesni_ecb_enc) * size_t len); */ ENTRY(aesni_ecb_dec) + FRAME_BEGIN #ifndef __x86_64__ pushl LEN pushl KEYP @@ -2401,6 +2411,7 @@ ENTRY(aesni_ecb_dec) popl KEYP popl LEN #endif + FRAME_END ret ENDPROC(aesni_ecb_dec) @@ -2409,6 +2420,7 @@ ENDPROC(aesni_ecb_dec) * size_t len, u8 *iv) */ ENTRY(aesni_cbc_enc) + FRAME_BEGIN #ifndef __x86_64__ pushl IVP pushl LEN @@ -2443,6 +2455,7 @@ ENTRY(aesni_cbc_enc) popl LEN popl IVP #endif + FRAME_END ret ENDPROC(aesni_cbc_enc) @@ -2451,6 +2464,7 @@ ENDPROC(aesni_cbc_enc) * size_t len, u8 *iv) */ ENTRY(aesni_cbc_dec) + FRAME_BEGIN #ifndef __x86_64__ pushl IVP pushl LEN @@ -2534,6 +2548,7 @@ ENTRY(aesni_cbc_dec) popl LEN popl IVP #endif + FRAME_END ret ENDPROC(aesni_cbc_dec) @@ -2598,6 +2613,7 @@ ENDPROC(_aesni_inc) * size_t len, u8 *iv) */ ENTRY(aesni_ctr_enc) + FRAME_BEGIN cmp $16, LEN jb .Lctr_enc_just_ret mov 480(KEYP), KLEN @@ -2651,6 +2667,7 @@ ENTRY(aesni_ctr_enc) .Lctr_enc_ret: movups IV, (IVP) .Lctr_enc_just_ret: + FRAME_END ret ENDPROC(aesni_ctr_enc) @@ -2677,6 +2694,7 @@ ENDPROC(aesni_ctr_enc) * bool enc, u8 *iv) */ ENTRY(aesni_xts_crypt8) + FRAME_BEGIN cmpb $0, %cl movl $0, %ecx movl $240, %r10d @@ -2777,6 +2795,7 @@ ENTRY(aesni_xts_crypt8) pxor INC, STATE4 movdqu STATE4, 0x70(OUTP) + FRAME_END ret ENDPROC(aesni_xts_crypt8) -- 2.4.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 v10 09/20] x86/amd: Set ELF function type for vide()
vide() is a callable function, but is missing the ELF function type,
which confuses tools like stackvalidate.
Properly annotate it to be a callable function. The generated code is
unchanged.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/cpu/amd.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 51ad2af..d19c9ad 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -74,7 +74,10 @@ static inline int wrmsrl_amd_safe(unsigned msr, unsigned
long long val)
*/
extern __visible void vide(void);
-__asm__(".globl vide\n\t.align 4\nvide: ret");
+__asm__(".globl vide\n"
+ ".type vide, @function\n"
+ ".align 4\n"
+ "vide: ret\n");
static void init_amd_k5(struct cpuinfo_x86 *c)
{
--
2.4.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 v10 10/20] x86/reboot: Add ljmp instructions to stackvalidate whitelist
stackvalidate reports a false positive warning for the ljmp instruction
in machine_real_restart(). Normally, ljmp isn't allowed in a function,
but this is a special case where it's jumping into real mode.
Add the jumps to a whitelist which tells stackvalidate to ignore them.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/reboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 86db4bc..0931d87 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -97,11 +98,13 @@ void __noreturn machine_real_restart(unsigned int type)
/* Jump to the identity-mapped low memory code */
#ifdef CONFIG_X86_32
- asm volatile("jmpl *%0" : :
+ asm volatile(STACKVALIDATE_IGNORE_INSN
+"jmpl *%0;" : :
"rm" (real_mode_header->machine_real_restart_asm),
"a" (type));
#else
- asm volatile("ljmpl *%0" : :
+ asm volatile(STACKVALIDATE_IGNORE_INSN
+"ljmpl *%0" : :
"m" (real_mode_header->machine_real_restart_asm),
"D" (type));
#endif
--
2.4.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 v10 13/20] x86/asm/crypto: Move .Lbswap_mask data to .rodata section
stackvalidate reports the following warning: stackvalidate: arch/x86/crypto/aesni-intel_asm.o: _aesni_inc_init(): can't find starting instruction stackvalidate gets confused when it tries to disassemble the following data in the .text section: .Lbswap_mask: .byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 Move it to .rodata which is a more appropriate section for read-only data. Signed-off-by: Josh Poimboeuf Cc: Herbert Xu Cc: "David S. Miller" --- arch/x86/crypto/aesni-intel_asm.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 289ef12..18f0ced 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -2553,9 +2553,11 @@ ENTRY(aesni_cbc_dec) ENDPROC(aesni_cbc_dec) #ifdef __x86_64__ +.pushsection .rodata .align 16 .Lbswap_mask: .byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 +.popsection /* * _aesni_inc_init:internal ABI -- 2.4.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 v10 14/20] x86/asm/crypto: Move jump_table to .rodata section
stackvalidate reports the following warning: stackvalidate: arch/x86/crypto/crc32c-pcl-intel-asm_64.o: crc_pcl()+0x11dd: can't decode instruction It gets confused when trying to decode jump_table data. Move jump_table to the .rodata section which is a more appropriate home for read-only data. Signed-off-by: Josh Poimboeuf Cc: Herbert Xu Cc: "David S. Miller" --- arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S index 225be06..dc05f01 100644 --- a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S +++ b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S @@ -170,8 +170,8 @@ continue_block: ## branch into array lea jump_table(%rip), bufp movzxw (bufp, %rax, 2), len - offset=crc_array-jump_table - lea offset(bufp, len, 1), bufp + lea crc_array(%rip), bufp + lea (bufp, len, 1), bufp jmp *bufp @@ -310,7 +310,9 @@ do_return: popq%rdi popq%rbx ret +ENDPROC(crc_pcl) +.section .rodata, "a", %progbits ## jump tableTable is 129 entries x 2 bytes each @@ -324,13 +326,11 @@ JMPTBL_ENTRY %i i=i+1 .endr -ENDPROC(crc_pcl) ## PCLMULQDQ tables ## Table is 128 entries x 2 words (8 bytes) each -.section .rotata, "a", %progbits .align 8 K_table: .long 0x493c7d27, 0x0001 -- 2.4.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 v10 11/20] x86/xen: Add xen_cpuid() and xen_setup_gdt() to stackvalidate whitelists
stackvalidate reports the following false positive warnings:
stackvalidate: arch/x86/xen/enlighten.o: xen_cpuid()+0x41: can't find jump
dest instruction at .text+0x108
stackvalidate: arch/x86/xen/enlighten.o: xen_setup_gdt.constprop.23()+0x2e:
kernel entry/exit from callable instruction
The first warning is due to xen_cpuid()'s use of XEN_EMULATE_PREFIX to
insert some fake instructions which stackvalidate doesn't know how to
decode.
The second warning is due to xen_setup_gdt()'s use of an lret
instruction, which stackvalidate normally doesn't allow in callable
functions. But this seems to be a valid use of the instruction.
Add both functions to the stackvalidate whitelist.
Signed-off-by: Josh Poimboeuf
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
arch/x86/xen/enlighten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d9cfa45..4ca89ac 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -345,8 +346,8 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
*cx &= maskecx;
*cx |= setecx;
*dx &= maskedx;
-
}
+STACKVALIDATE_IGNORE_FUNC(xen_cpuid);
static bool __init xen_check_mwait(void)
{
@@ -1443,6 +1444,7 @@ static void __ref xen_setup_gdt(int cpu)
pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry;
pv_cpu_ops.load_gdt = xen_load_gdt;
}
+STACKVALIDATE_IGNORE_FUNC(xen_setup_gdt);
#ifdef CONFIG_XEN_PVH
/*
--
2.4.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 v10 18/20] x86/asm: Create stack frames in rwsem functions
rwsem.S has several callable non-leaf functions which don't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create stack frames for them when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf --- arch/x86/lib/rwsem.S | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S index 40027db..be110ef 100644 --- a/arch/x86/lib/rwsem.S +++ b/arch/x86/lib/rwsem.S @@ -15,6 +15,7 @@ #include #include +#include #define __ASM_HALF_REG(reg)__ASM_SEL(reg, e##reg) #define __ASM_HALF_SIZE(inst) __ASM_SEL(inst##w, inst##l) @@ -84,24 +85,29 @@ /* Fix up special calling conventions */ ENTRY(call_rwsem_down_read_failed) + FRAME_BEGIN save_common_regs __ASM_SIZE(push,) %__ASM_REG(dx) movq %rax,%rdi call rwsem_down_read_failed __ASM_SIZE(pop,) %__ASM_REG(dx) restore_common_regs + FRAME_END ret ENDPROC(call_rwsem_down_read_failed) ENTRY(call_rwsem_down_write_failed) + FRAME_BEGIN save_common_regs movq %rax,%rdi call rwsem_down_write_failed restore_common_regs + FRAME_END ret ENDPROC(call_rwsem_down_write_failed) ENTRY(call_rwsem_wake) + FRAME_BEGIN /* do nothing if still outstanding active readers */ __ASM_HALF_SIZE(dec) %__ASM_HALF_REG(dx) jnz 1f @@ -109,15 +115,18 @@ ENTRY(call_rwsem_wake) movq %rax,%rdi call rwsem_wake restore_common_regs -1: ret +1: FRAME_END + ret ENDPROC(call_rwsem_wake) ENTRY(call_rwsem_downgrade_wake) + FRAME_BEGIN save_common_regs __ASM_SIZE(push,) %__ASM_REG(dx) movq %rax,%rdi call rwsem_downgrade_wake __ASM_SIZE(pop,) %__ASM_REG(dx) restore_common_regs + FRAME_END ret ENDPROC(call_rwsem_downgrade_wake) -- 2.4.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 v10 16/20] x86/asm/entry: Create stack frames in thunk functions
Thunk functions are callable non-leaf functions that don't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Also they aren't annotated as ELF callable functions which can confuse tooling. Create stack frames for them when CONFIG_FRAME_POINTER is enabled and add the ELF function type. Signed-off-by: Josh Poimboeuf --- arch/x86/entry/thunk_64.S | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/entry/thunk_64.S b/arch/x86/entry/thunk_64.S index efb2b93..98df1fa 100644 --- a/arch/x86/entry/thunk_64.S +++ b/arch/x86/entry/thunk_64.S @@ -8,11 +8,14 @@ #include #include "calling.h" #include +#include /* rdi: arg1 ... normal C conventions. rax is saved/restored. */ .macro THUNK name, func, put_ret_addr_in_rdi=0 .globl \name + .type \name, @function \name: + FRAME_BEGIN /* this one pushes 9 elems, the next one would be %rIP */ pushq %rdi @@ -62,6 +65,7 @@ restore: popq %rdx popq %rsi popq %rdi + FRAME_END ret _ASM_NOKPROBE(restore) #endif -- 2.4.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 v10 17/20] x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()
do_suspend_lowlevel() is a callable non-leaf function which doesn't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create a stack frame for it when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf Acked-by: Pavel Machek Cc: "Rafael J. Wysocki" Cc: Len Brown --- arch/x86/kernel/acpi/wakeup_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S index 8c35df4..169963f 100644 --- a/arch/x86/kernel/acpi/wakeup_64.S +++ b/arch/x86/kernel/acpi/wakeup_64.S @@ -5,6 +5,7 @@ #include #include #include +#include # Copyright 2003 Pavel Machek , distribute under GPLv2 @@ -39,6 +40,7 @@ bogus_64_magic: jmp bogus_64_magic ENTRY(do_suspend_lowlevel) + FRAME_BEGIN subq$8, %rsp xorl%eax, %eax callsave_processor_state @@ -109,6 +111,7 @@ ENTRY(do_suspend_lowlevel) xorl%eax, %eax addq$8, %rsp + FRAME_END jmp restore_processor_state ENDPROC(do_suspend_lowlevel) -- 2.4.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 v10 20/20] x86/asm/power: Create stack frames in hibernate_asm_64.S
swsusp_arch_suspend() and restore_registers() are callable non-leaf functions which don't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Also they aren't annotated as ELF callable functions which can confuse tooling. Create a stack frame for them when CONFIG_FRAME_POINTER is enabled and give them proper ELF function annotations. Signed-off-by: Josh Poimboeuf Acked-by: Pavel Machek Cc: "Rafael J. Wysocki" --- arch/x86/power/hibernate_asm_64.S | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/power/hibernate_asm_64.S b/arch/x86/power/hibernate_asm_64.S index e2386cb..4400a43 100644 --- a/arch/x86/power/hibernate_asm_64.S +++ b/arch/x86/power/hibernate_asm_64.S @@ -21,8 +21,10 @@ #include #include #include +#include ENTRY(swsusp_arch_suspend) + FRAME_BEGIN movq$saved_context, %rax movq%rsp, pt_regs_sp(%rax) movq%rbp, pt_regs_bp(%rax) @@ -50,7 +52,9 @@ ENTRY(swsusp_arch_suspend) movq%rax, restore_cr3(%rip) call swsusp_save + FRAME_END ret +ENDPROC(swsusp_arch_suspend) ENTRY(restore_image) /* switch to temporary page tables */ @@ -107,6 +111,7 @@ ENTRY(core_restore_code) */ ENTRY(restore_registers) + FRAME_BEGIN /* go back to the original page tables */ movq%rbx, %cr3 @@ -147,4 +152,6 @@ ENTRY(restore_registers) /* tell the hibernation core that we've just restored the memory */ movq%rax, in_suspend(%rip) + FRAME_END ret +ENDPROC(restore_registers) -- 2.4.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 v10 19/20] x86/asm/efi: Create a stack frame in efi_call()
efi_call() is a callable non-leaf function which doesn't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create a stack frame for it when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf Cc: Matt Fleming --- arch/x86/platform/efi/efi_stub_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/platform/efi/efi_stub_64.S b/arch/x86/platform/efi/efi_stub_64.S index 86d0f9e..0df2dcc 100644 --- a/arch/x86/platform/efi/efi_stub_64.S +++ b/arch/x86/platform/efi/efi_stub_64.S @@ -11,6 +11,7 @@ #include #include #include +#include #define SAVE_XMM \ mov %rsp, %rax; \ @@ -74,6 +75,7 @@ .endm ENTRY(efi_call) + FRAME_BEGIN SAVE_XMM mov (%rsp), %rax mov 8(%rax), %rax @@ -88,6 +90,7 @@ ENTRY(efi_call) RESTORE_PGT addq $48, %rsp RESTORE_XMM + FRAME_END ret ENDPROC(efi_call) -- 2.4.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 v10 15/20] x86/asm/crypto: Create stack frames in clmul_ghash_mul/update()
clmul_ghash_mul() and clmul_ghash_update() are callable non-leaf functions which don't honor CONFIG_FRAME_POINTER, which can result in bad stack traces. Create stack frames for them when CONFIG_FRAME_POINTER is enabled. Signed-off-by: Josh Poimboeuf Cc: Herbert Xu Cc: "David S. Miller" --- arch/x86/crypto/ghash-clmulni-intel_asm.S | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S b/arch/x86/crypto/ghash-clmulni-intel_asm.S index 5d1e007..eed55c8 100644 --- a/arch/x86/crypto/ghash-clmulni-intel_asm.S +++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S @@ -18,6 +18,7 @@ #include #include +#include .data @@ -94,6 +95,7 @@ ENDPROC(__clmul_gf128mul_ble) /* void clmul_ghash_mul(char *dst, const u128 *shash) */ ENTRY(clmul_ghash_mul) + FRAME_BEGIN movups (%rdi), DATA movups (%rsi), SHASH movaps .Lbswap_mask, BSWAP @@ -101,6 +103,7 @@ ENTRY(clmul_ghash_mul) call __clmul_gf128mul_ble PSHUFB_XMM BSWAP DATA movups DATA, (%rdi) + FRAME_END ret ENDPROC(clmul_ghash_mul) @@ -109,6 +112,7 @@ ENDPROC(clmul_ghash_mul) *const u128 *shash); */ ENTRY(clmul_ghash_update) + FRAME_BEGIN cmp $16, %rdx jb .Lupdate_just_ret# check length movaps .Lbswap_mask, BSWAP @@ -128,5 +132,6 @@ ENTRY(clmul_ghash_update) PSHUFB_XMM BSWAP DATA movups DATA, (%rdi) .Lupdate_just_ret: + FRAME_END ret ENDPROC(clmul_ghash_update) -- 2.4.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 2/2] soc/fsl: add ftm alarm driver for ls1021a platform
> -Original Message- > From: Linus Walleij [mailto:linus.wall...@linaro.org] > Sent: Thursday, August 13, 2015 9:54 PM > To: Wang Dongsheng-B40534; John Stultz; Alessandro Zummo; Alexandre Belloni > Cc: Shawn Guo; Nair, Sandeep; Hans de Goede; Wang Huan-B18965; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; rtc- > li...@googlegroups.com > Subject: Re: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform > > On Wed, Aug 12, 2015 at 7:53 AM, Dongsheng Wang > wrote: > > > From: Wang Dongsheng > > > > Only Ftm0 can be used when system going to deep sleep. So this driver > > to support ftm0 as a wakeup source. > > > > Signed-off-by: Wang Dongsheng > > --- > > *V2* > > Change Copyright 2014 to 2015. > (...) > > +config FTM_ALARM > > + bool "FTM alarm driver" > > + depends on SOC_LS1021A > > + default n > > + help > > + Say y here to enable FTM alarm support. The FTM alarm provides > > + alarm functions for wakeup system from deep sleep. There is only > > + one FTM can be used in ALARM(FTM 0). > (...) > > +static u32 time_to_cycle(unsigned long time) > > +static u32 cycle_to_time(u32 cycle) > > +static int ftm_set_alarm(u64 cycle) > > +static irqreturn_t ftm_alarm_interrupt(int irq, void *dev_id) > > +static ssize_t ftm_alarm_show(struct device *dev, > > + struct device_attribute *attr, > > + char *buf) > > +static ssize_t ftm_alarm_store(struct device *dev, > > + struct device_attribute *attr, > > + const char *buf, size_t count) > (...) > > +static struct device_attribute ftm_alarm_attributes = __ATTR(ftm_alarm, > > 0644, > > + ftm_alarm_show, ftm_alarm_store); > > If you're gonna invent ABIs, document then in Documentation/ABI/testing/*. > > But I don't get it. Why is this driver not in drivers/rtc? > > It does a subset of what an RTC does. The ioctl()'s of an RTC > can do what you want to do. And much much more. > > If it can't do all an RTC can do, surely the RTC subsystem > can be augmented to host it anyway. It's way to close to > an RTC to have it's own random sysfs driver like this. > > Unless I'm totally off, rewrite this to an RTC driver and post > it to the RTC maintainers. > FlexTimer is not a RTC device and not have any rtc deivce function. They belong to different devices, why we need to register this to RTC framework? I am confused about this. Now in freescale layerscape platform this driver is only for FlexTimer0, and not fit for each flextimer. Because only FlexTimer0 still turn-on when system in the Deep Sleep. If the "alarm" make you feel confused or mislead you think this is a RTC devices. I think I need to change the "alarm" to "timer". Regards, -Dongsheng
[PATCH v10 01/20] x86/asm: Frame pointer macro cleanup
The asm macros for setting up and restoring the frame pointer aren't currently being used. However, they will be needed soon to help asm functions to comply with stackvalidate. Rename FRAME/ENDFRAME to FRAME_BEGIN/FRAME_END for more symmetry. Also make the code more readable and improve the comments. Signed-off-by: Josh Poimboeuf --- arch/x86/include/asm/frame.h | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/frame.h b/arch/x86/include/asm/frame.h index 793179c..8a6cd26 100644 --- a/arch/x86/include/asm/frame.h +++ b/arch/x86/include/asm/frame.h @@ -1,23 +1,26 @@ +#ifndef _ASM_X86_FRAME_H +#define _ASM_X86_FRAME_H + #ifdef __ASSEMBLY__ #include -/* The annotation hides the frame from the unwinder and makes it look - like a ordinary ebp save/restore. This avoids some special cases for - frame pointer later */ +/* + * These are stack frame creation macros. They should be used by every + * callable non-leaf asm function to make kernel stack traces more reliable. + */ +.macro FRAME_BEGIN +#ifdef CONFIG_FRAME_POINTER + push %_ASM_BP + _ASM_MOV %_ASM_SP, %_ASM_BP +#endif +.endm + +.macro FRAME_END #ifdef CONFIG_FRAME_POINTER - .macro FRAME - __ASM_SIZE(push,) %__ASM_REG(bp) - __ASM_SIZE(mov) %__ASM_REG(sp), %__ASM_REG(bp) - .endm - .macro ENDFRAME - __ASM_SIZE(pop,)%__ASM_REG(bp) - .endm -#else - .macro FRAME - .endm - .macro ENDFRAME - .endm + pop %_ASM_BP #endif +.endm #endif /* __ASSEMBLY__ */ +#endif /* _ASM_X86_FRAME_H */ -- 2.4.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 v10 06/20] x86/xen: Add stack frame dependency to hypercall inline asm calls
If a hypercall is inlined at the beginning of a function, gcc can insert
the call instruction before setting up a stack frame, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace.
Force a stack frame to be created if CONFIG_FRAME_POINTER is enabled by
listing the stack pointer as an output operand for the hypercall inline
asm statements.
Signed-off-by: Josh Poimboeuf
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
---
arch/x86/include/asm/xen/hypercall.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index ca08a27..4488fbc 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -110,9 +110,10 @@ extern struct { char _entry[32]; } hypercall_page[];
register unsigned long __arg2 asm(__HYPERCALL_ARG2REG) = __arg2; \
register unsigned long __arg3 asm(__HYPERCALL_ARG3REG) = __arg3; \
register unsigned long __arg4 asm(__HYPERCALL_ARG4REG) = __arg4; \
- register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5;
+ register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5; \
+ register void *__sp asm(_ASM_SP);
-#define __HYPERCALL_0PARAM "=r" (__res)
+#define __HYPERCALL_0PARAM "=r" (__res), "+r" (__sp)
#define __HYPERCALL_1PARAM __HYPERCALL_0PARAM, "+r" (__arg1)
#define __HYPERCALL_2PARAM __HYPERCALL_1PARAM, "+r" (__arg2)
#define __HYPERCALL_3PARAM __HYPERCALL_2PARAM, "+r" (__arg3)
--
2.4.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] lib/decompress_unlzma: Do a NULL check for pointer
From: Fabio Estevam Compare pointer-typed values to NULL rather than 0. The semantic patch that makes this change is available in scripts/coccinelle/null/badzero.cocci. Signed-off-by: Fabio Estevam --- lib/decompress_unlzma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/decompress_unlzma.c b/lib/decompress_unlzma.c index 0be83af..04d6813 100644 --- a/lib/decompress_unlzma.c +++ b/lib/decompress_unlzma.c @@ -620,7 +620,7 @@ STATIC inline int INIT unlzma(unsigned char *buf, long in_len, num_probs = LZMA_BASE_SIZE + (LZMA_LIT_SIZE << (lc + lp)); p = (uint16_t *) large_malloc(num_probs * sizeof(*p)); - if (p == 0) + if (p == NULL) goto exit_2; num_probs = LZMA_LITERAL + (LZMA_LIT_SIZE << (lc + lp)); for (i = 0; i < num_probs; 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] kvm:powerpc:Fix return statements for wrapper functions in the file book3s_64_mmu_hv.c
On Wed, 2015-08-12 at 21:06 +0200, Alexander Graf wrote: > > On 10.08.15 17:27, Nicholas Krause wrote: > > This fixes the wrapper functions kvm_umap_hva_hv and the function > > kvm_unmap_hav_range_hv to return the return value of the function > > kvm_handle_hva or kvm_handle_hva_range that they are wrapped to > > call internally rather then always making the caller of these > > wrapper functions think they always run successfully by returning > > the value of zero directly. > > > > Signed-off-by: Nicholas Krause > > Paul, could you please take on this one? Paul's away for a while can you take it directly? 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: i915/kasan: out of bounds access in i915_cmd_parser_init_ring
On 14 August 2015 at 11:09, Dave Jones wrote: > I finally got around to playing with kasan. It didn't end well. > > I added some debugging to validate_cmds_sorted to print out the table > sizes right before the stack traces. oops typo, patch sent. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/6] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL
On 08/08/2015 02:02 AM, Peter Zijlstra wrote: On Fri, Aug 07, 2015 at 11:17:56PM -0400, Waiman Long wrote: If _Q_SLOW_VAL has been set, the vCPU state must have been vcpu_hashed. The extra check at the end of __pv_queued_spin_unlock() is unnecessary and so is removed. This is half the patch it should be. Because if the load is not needed, then the store is not either, and then there's the comments to update. Sorry for the late reply. That is true. Setting state to vcpu_hashed in pv_wait_head() isn't really necessary. I kept it there for consistency sake as the state may be set to vcpu_hashed in pv_kick_node(). We can certainly take that out. BTW, could you also review the other patches when you have time? I am coming to the LinuxCon/Plumbers next week. Hopefully, I can chat with you again. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_irq.c
between commit:
209e4dbc8dcd ("drm/vblank: Use u32 consistently for vblank counters")
from Linus' tree and commit:
b90180b057f7 ("drm/irq: More pipe/crtc consistency cleanups")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/drm_irq.c
index ee14324522ce,70919d48f015..
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@@ -74,11 -74,11 +74,11 @@@ module_param_named(vblankoffdelay, drm_
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
- static void store_vblank(struct drm_device *dev, int crtc,
+ static void store_vblank(struct drm_device *dev, unsigned int pipe,
- unsigned vblank_count_inc,
+ u32 vblank_count_inc,
struct timeval *t_vblank)
{
- struct drm_vblank_crtc *vblank = >vblank[crtc];
+ struct drm_vblank_crtc *vblank = >vblank[pipe];
u32 tslot;
assert_spin_locked(>vblank_time_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: core: Spell fix
On 13-08-15, 14:15, Mark Brown wrote: > On Thu, Aug 13, 2015 at 06:09:49PM +0530, Viresh Kumar wrote: > > Trivial spell fix, s/succesfully/successfully. > > That's "spelling fix" not "spell fix" :) :( Thanks for fixing/applying it :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
14.08.2015 04:37, Andy Lutomirski пишет: On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote: 14.08.2015 04:21, Andy Lutomirski пишет: On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote: 14.08.2015 03:27, Linus Torvalds пишет: On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote: For example because you can as well do: prctl(ARCH_SET_SIGNAL_SS, 0) which will mean "restore ss in sighandler to its current value", I really think a prctl() is the wrong thing to do. If you want a signal handler to save/restore segments, I think it should be a SA_xyz flag to sigaction() (the way we have SA_RESTART Yes, I was proposing the new sigaction() flag in this thread already too. But at the end, prctl() looks better to me because it allows to pass the TLS value to use when restoring FS. The thing is that I am trying to find the similar treatment for both the SS and FS problems. If you don't think they need a similar treatment, then perhaps the Andy's patch is enough. etc). And off by default because of the obvious compatibility issues. Of course. So, what we have right now (in the latest Andy's patch) is: 1. lar heuristics 2. new uc_flags flag What it solves: dosemu's regression. What prctl() can give: - fix to dosemu's regression - fix to the TLS problem in the future - no hack and heuristics With SA_xyz you can only solve the SS problem, so it is probably not any better than the uc_flags things coded up by Andy. I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. Stop right here, doesn't the SA_xyz allow to avoid the lar heuristic? Why would you still need the lar heuristic then? Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and the lar heuristic is gone. The LAR heuristic is about five lines of code, and it makes signal delivery more reliable. Sure, we could gate the "regs->ss = __USER_DS" line on a flag, but why? Speed? I'll let others decide on that. My vote is to no heuristic if possible, and keeping the FS problem in mind if possible (obviously, both are possible). Unfortunately, I don't think we were clever enough to allow this to be probed easily -- we silently ignore unrecognized sa_flags bits. Big deal, check the kversion. :) Not so good. For example, if you made your DOSEMU patch to use the saved SS check the version, then the backported revert would break you. I would be scared to imagine the program that probes for everything, adding more and more probes with years, instead of just saying "you need kernel version at least x.y.z". If some functionality is reverted, another kversion check can be added. This all is not new: dosemu's protected mode implementation doesn't work on many kernels selectively. IIRC it didn't work on 3.14 because the 16bit LDTs were disallowed, and other versions had problems too. It is easier to ban such kernels by versions instead of adding a run-time probes, because you don't know beforehand what will break in the next kernel to add a probe in advance, and when you react to an existing breakage, it already doesn't matter. The possibly of reverting a new functionality is similar to getting a breakage in an existing functionality (or even have lower probability), so I see no reason to choose different treatments for these two. But of course every author has own habits. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-tegra tree with the drm-misc tree
Hi Thierry,
Today's linux-next merge of the drm-tegra tree got conflicts in:
drivers/gpu/drm/tegra/dsi.c
drivers/gpu/drm/tegra/hdmi.c
drivers/gpu/drm/tegra/rgb.c
drivers/gpu/drm/tegra/sor.c
between commit:
9a69a9ac20f7 ("drm: Make the connector dpms callback return a value, v2")
from the drm-misc tree and commits:
171e2e6dd912 ("drm/tegra: dsi: Restore DPMS")
29871b21c48c ("drm/tegra: hdmi: Restore DPMS")
32c3dee11e8e ("drm/tegra: rgb: Restore DPMS")
850bab448034 ("drm/tegra: sor: Restore DPMS")
from the drm-tegra tree.
I fixed it up (the latter commits removed the code updated by the former)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MODSIGN: Use PKCS#7 for module signatures [ver #8a]
On Thu, 13 Aug 2015, David Howells wrote: > Hi James, > > Can you pull this into security/next please? Its aim is twofold: firstly, > make the module signatures of PKCS#7/CMS format rather than a home-brewed > format and secondly to pave the way for use of the signing code for > firmware signatures (to follow later). Pulled into -next. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: acpi: Generic function for setting up PCI device DMA coherency
Hi Suravee,
On Thu, Aug 13, 2015 at 04:58:45PM +0700, Suravee Suthikulpanit wrote:
> This patch refactors of_pci_dma_configure() into a more generic
> pci_dma_configure(), which can be reused by non-OF code.
> Then, it adds support for setting up PCI device DMA coherency from
> ACPI _CCA object that should normally be specified in the DSDT node
> of its PCI host bridge..
Since this does two things:
1) Rename of_pci_dma_configure() and move it to PCI
2) Add _CCA support,
maybe it should be split into two patches?
There are a couple more comments below.
While looking at this, I thought some of the existing code could be
made simpler and easier to follow. I appended a couple possible patches;
you can incorporate them or ignore them, whatever seems best to you.
Bjorn
> Signed-off-by: Suravee Suthikulpanit
> CC: Bjorn Helgaas
> CC: Catalin Marinas
> CC: Will Deacon
> CC: Rafael J. Wysocki
> CC: Rob Herring
> CC: Murali Karicheri
> ---
> Note: According to the ACPI spec, the _CCA attribute is required
> for ARM64. Therefore, this patch is a pre-req for ACPI PCI
> support for ARM64 which is currently in development.
>
> Also, this should not affect other architectures since
> if CCA is not required, the default value is coherent.
> Please see include/acpi/acpi_bus.h: acpi_check_dma() and
> drivers/acpi/scan.c: acpi_init_coherency() for more information
>
> drivers/of/of_pci.c| 20
> drivers/pci/probe.c| 35 +--
> include/linux/of_pci.h | 3 ---
> 3 files changed, 33 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..b66ee4e 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -117,26 +117,6 @@ int of_get_pci_domain_nr(struct device_node *node)
> }
> EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
>
> -/**
> - * of_pci_dma_configure - Setup DMA configuration
> - * @dev: ptr to pci_dev struct of the PCI device
> - *
> - * Function to update PCI devices's DMA configuration using the same
> - * info from the OF node of host bridge's parent (if any).
> - */
> -void of_pci_dma_configure(struct pci_dev *pci_dev)
> -{
> - struct device *dev = _dev->dev;
> - struct device *bridge = pci_get_host_bridge_device(pci_dev);
> -
> - if (!bridge->parent)
> - return;
> -
> - of_dma_configure(dev, bridge->parent->of_node);
> - pci_put_host_bridge_device(bridge);
> -}
> -EXPORT_SYMBOL_GPL(of_pci_dma_configure);
> -
> #if defined(CONFIG_OF_ADDRESS)
> /**
> * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index cefd636..e2fcd3b 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -6,12 +6,14 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include "pci.h"
>
> @@ -1544,6 +1546,35 @@ static void pci_init_capabilities(struct pci_dev *dev)
> pci_enable_acs(dev);
> }
>
> +/**
> + * pci_dma_configure - Setup DMA configuration
> + * @pci_dev: ptr to pci_dev struct of the PCI device
> + *
> + * Function to update PCI devices's DMA configuration using the same
> + * info from the OF node or ACPI node of host bridge's parent (if any).
> + */
> +static void pci_dma_configure(struct pci_dev *pci_dev)
Almost all pci_dev pointers in probe.c are named "dev", so I would use
that for this one, too. I probably would just drop the "struct device
*dev" below and use ">dev" the two places you need it. That's a
common idiom in PCI.
> +{
> + struct device *dev = _dev->dev;
> + struct device *bridge = pci_get_host_bridge_device(pci_dev);
> + struct acpi_device *adev;
> + bool coherent;
> +
> + if (has_acpi_companion(bridge)) {
> + adev = to_acpi_node(bridge->fwnode);
> + if (acpi_check_dma(adev, ))
> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
> + } else {
> + struct device *host = bridge->parent;
> + if (!host)
> + return;
> +
> + of_dma_configure(dev, host->of_node);
> + }
Why is this check reversed with respect to device_dma_is_coherent()?
In device_dma_is_coherent(), we first look for an OF property, then look
for ACPI _CCA. But here we check for _CCA, then for OF.
> +
> + pci_put_host_bridge_device(bridge);
> +}
> +
> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> {
> int ret;
> @@ -1557,7 +1588,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
> *bus)
> dev->dev.dma_mask = >dma_mask;
> dev->dev.dma_parms = >dma_parms;
> dev->dev.coherent_dma_mask = 0xull;
> - of_pci_dma_configure(dev);
> + pci_dma_configure(dev);
>
> pci_set_dma_max_seg_size(dev, 65536);
>
[PATCH v4 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list usage
These objects can be referenced concurrently throughout the driver, we
need a way to make sure threads can't delete them out from under each
other. This patch adds the refcount, and refactors the code to use it.
Additionally, we cannot iterate over the sas_device_list without
holding the lock, or we risk corrupting random memory if items are
added or deleted as we iterate. This patch refactors _scsih_probe_sas()
to use the sas_device_list in a safe way.
Cc: Christoph Hellwig
Cc: Bart Van Assche
Cc: Joe Lawrence
Signed-off-by: Calvin Owens
---
Changes in v4:
* Fix lack of put() in non-SATA case in _scsih_change_queue_depth()
* Fix lack of put() in the non-error case in _scsih_check_device()
* Add missing put() at bottom of _scsih_add_device()
* Add put for ->hostdata pointer in _scsih_target_destroy() for the
get() in _scsih_target_alloc()
Changes in v3:
* Drop the sas_device_lock while enabling devices, and leave the
sas_device object on the list, since it may need to be looked up there
while it is being enabled.
* Drop put() in _scsih_add_device(), because the ->hostdata now keeps a
reference (this was an oversight in v2).
* Be consistent about calling sas_device_put() while holding the
sas_device_lock where feasible.
* Take and assert_spin_locked() on the sas_device_lock from the newly
added __get_sdev_from_target(), add wrapper similar to other lookups
for callers which do not explicitly take the lock.
Changes in v2:
* Squished patches 1-3 into this one
* s/BUG_ON(!spin_is_locked/assert_spin_locked/g
* Store a pointer to the sas_device object in ->hostdata, to eliminate
the need for several lookups on the lists.
drivers/scsi/mpt2sas/mpt2sas_base.h | 22 +-
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 480 +--
drivers/scsi/mpt2sas/mpt2sas_transport.c | 12 +-
3 files changed, 360 insertions(+), 154 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h
b/drivers/scsi/mpt2sas/mpt2sas_base.h
index caff8d1..78f41ac 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.h
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.h
@@ -238,6 +238,7 @@
* @flags: MPT_TARGET_FLAGS_XXX flags
* @deleted: target flaged for deletion
* @tm_busy: target is busy with TM request.
+ * @sdev: The sas_device associated with this target
*/
struct MPT2SAS_TARGET {
struct scsi_target *starget;
@@ -248,6 +249,7 @@ struct MPT2SAS_TARGET {
u32 flags;
u8 deleted;
u8 tm_busy;
+ struct _sas_device *sdev;
};
@@ -376,8 +378,24 @@ struct _sas_device {
u8 phy;
u8 responding;
u8 pfa_led_on;
+ struct kref refcount;
};
+static inline void sas_device_get(struct _sas_device *s)
+{
+ kref_get(>refcount);
+}
+
+static inline void sas_device_free(struct kref *r)
+{
+ kfree(container_of(r, struct _sas_device, refcount));
+}
+
+static inline void sas_device_put(struct _sas_device *s)
+{
+ kref_put(>refcount, sas_device_free);
+}
+
/**
* struct _raid_device - raid volume link list
* @list: sas device list
@@ -1095,7 +1113,9 @@ struct _sas_node
*mpt2sas_scsih_expander_find_by_handle(struct MPT2SAS_ADAPTER *
u16 handle);
struct _sas_node *mpt2sas_scsih_expander_find_by_sas_address(struct
MPT2SAS_ADAPTER
*ioc, u64 sas_address);
-struct _sas_device *mpt2sas_scsih_sas_device_find_by_sas_address(
+struct _sas_device *mpt2sas_get_sdev_by_addr(
+struct MPT2SAS_ADAPTER *ioc, u64 sas_address);
+struct _sas_device *__mpt2sas_get_sdev_by_addr(
struct MPT2SAS_ADAPTER *ioc, u64 sas_address);
void mpt2sas_port_enable_complete(struct MPT2SAS_ADAPTER *ioc);
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 3f26147..5eca3a4 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -526,8 +526,61 @@ _scsih_determine_boot_device(struct MPT2SAS_ADAPTER *ioc,
}
}
+static struct _sas_device *
+__mpt2sas_get_sdev_from_target(struct MPT2SAS_ADAPTER *ioc,
+ struct MPT2SAS_TARGET *tgt_priv)
+{
+ struct _sas_device *ret;
+
+ assert_spin_locked(>sas_device_lock);
+
+ ret = tgt_priv->sdev;
+ if (ret)
+ sas_device_get(ret);
+
+ return ret;
+}
+
+static struct _sas_device *
+mpt2sas_get_sdev_from_target(struct MPT2SAS_ADAPTER *ioc,
+ struct MPT2SAS_TARGET *tgt_priv)
+{
+ struct _sas_device *ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(>sas_device_lock, flags);
+ ret = __mpt2sas_get_sdev_from_target(ioc, tgt_priv);
+ spin_unlock_irqrestore(>sas_device_lock, flags);
+
+ return ret;
+}
+
+
+struct _sas_device *
+__mpt2sas_get_sdev_by_addr(struct MPT2SAS_ADAPTER *ioc,
+u64 sas_address)
+{
+ struct _sas_device
Re: [PATCH] usb: phy: phy-generic: Fix reset behaviour on legacy boot
On Thu, Aug 13, 2015 at 7:28 AM, Roger Quadros wrote:
> The gpio-desc migration done in v4.0 caused a regression
> with legacy boots due to reversed reset logic.
> e.g. omap3-beagle USB host breaks on legacy boot.
>
> Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that
> it matches the driver logic and pin behaviour.
>
> Fixes: e9f2cefb0cdc ("usb: phy: generic: migrate to gpio_desc")
> Cc: # 4.0+
> Signed-off-by: Roger Quadros
The USB on my mx51-babbage board still works fine with this change:
Tested-by: Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] mpt2sas: Refcount fw_events and fix unsafe list usage
The fw_event_work struct is concurrently referenced at shutdown, so
add a refcount to protect it, and refactor the code to use it.
Additionally, refactor _scsih_fw_event_cleanup_queue() such that it
no longer iterates over the list without holding the lock, since
_firmware_event_work() concurrently deletes items from the list.
Cc: Christoph Hellwig
Signed-off-by: Calvin Owens
---
Changes in v4: None
Changes in v3:
* Add a break condition to the REMOVE_UNRESPONDING_DEVICES fw_event,
which can loop over a sleep forever (5m+ at least) at unloading. I
don't think anything prevented this before, but taking the fw_event
object off the list at the top of _firmware_event_work() seems to have
made it more likely to happen.
Changes in v2:
* Squished patches 4-6 into one patch
* Remove the fw_event from fw_event_list at the start of
_firmware_event_work()
* Explicitly seperate fw_event_list removal from fw_event freeing
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 112 ---
1 file changed, 91 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
index 5eca3a4..c0ff55b 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
@@ -176,9 +176,37 @@ struct fw_event_work {
u8 VP_ID;
u8 ignore;
u16 event;
+ struct kref refcount;
charevent_data[0] __aligned(4);
};
+static void fw_event_work_free(struct kref *r)
+{
+ kfree(container_of(r, struct fw_event_work, refcount));
+}
+
+static void fw_event_work_get(struct fw_event_work *fw_work)
+{
+ kref_get(_work->refcount);
+}
+
+static void fw_event_work_put(struct fw_event_work *fw_work)
+{
+ kref_put(_work->refcount, fw_event_work_free);
+}
+
+static struct fw_event_work *alloc_fw_event_work(int len)
+{
+ struct fw_event_work *fw_event;
+
+ fw_event = kzalloc(sizeof(*fw_event) + len, GFP_ATOMIC);
+ if (!fw_event)
+ return NULL;
+
+ kref_init(_event->refcount);
+ return fw_event;
+}
+
/* raid transport support */
static struct raid_template *mpt2sas_raid_template;
@@ -2872,36 +2900,39 @@ _scsih_fw_event_add(struct MPT2SAS_ADAPTER *ioc, struct
fw_event_work *fw_event)
return;
spin_lock_irqsave(>fw_event_lock, flags);
+ fw_event_work_get(fw_event);
list_add_tail(_event->list, >fw_event_list);
INIT_DELAYED_WORK(_event->delayed_work, _firmware_event_work);
+ fw_event_work_get(fw_event);
queue_delayed_work(ioc->firmware_event_thread,
_event->delayed_work, 0);
spin_unlock_irqrestore(>fw_event_lock, flags);
}
/**
- * _scsih_fw_event_free - delete fw_event
+ * _scsih_fw_event_del_from_list - delete fw_event from the list
* @ioc: per adapter object
* @fw_event: object describing the event
* Context: This function will acquire ioc->fw_event_lock.
*
- * This removes firmware event object from link list, frees associated memory.
+ * If the fw_event is on the fw_event_list, remove it and do a put.
*
* Return nothing.
*/
static void
-_scsih_fw_event_free(struct MPT2SAS_ADAPTER *ioc, struct fw_event_work
+_scsih_fw_event_del_from_list(struct MPT2SAS_ADAPTER *ioc, struct fw_event_work
*fw_event)
{
unsigned long flags;
spin_lock_irqsave(>fw_event_lock, flags);
- list_del(_event->list);
- kfree(fw_event);
+ if (!list_empty(_event->list)) {
+ list_del_init(_event->list);
+ fw_event_work_put(fw_event);
+ }
spin_unlock_irqrestore(>fw_event_lock, flags);
}
-
/**
* _scsih_error_recovery_delete_devices - remove devices not responding
* @ioc: per adapter object
@@ -2916,13 +2947,14 @@ _scsih_error_recovery_delete_devices(struct
MPT2SAS_ADAPTER *ioc)
if (ioc->is_driver_loading)
return;
- fw_event = kzalloc(sizeof(struct fw_event_work), GFP_ATOMIC);
+ fw_event = alloc_fw_event_work(0);
if (!fw_event)
return;
fw_event->event = MPT2SAS_REMOVE_UNRESPONDING_DEVICES;
fw_event->ioc = ioc;
_scsih_fw_event_add(ioc, fw_event);
+ fw_event_work_put(fw_event);
}
/**
@@ -2936,12 +2968,29 @@ mpt2sas_port_enable_complete(struct MPT2SAS_ADAPTER
*ioc)
{
struct fw_event_work *fw_event;
- fw_event = kzalloc(sizeof(struct fw_event_work), GFP_ATOMIC);
+ fw_event = alloc_fw_event_work(0);
if (!fw_event)
return;
fw_event->event = MPT2SAS_PORT_ENABLE_COMPLETE;
fw_event->ioc = ioc;
_scsih_fw_event_add(ioc, fw_event);
+ fw_event_work_put(fw_event);
+}
+
+static struct fw_event_work *dequeue_next_fw_event(struct MPT2SAS_ADAPTER *ioc)
+{
+ unsigned
[PATCH v4 0/2] Fixes for memory corruption in mpt2sas
Hello all, This patchset attempts to address problems we've been having with panics due to memory corruption from the mpt2sas driver. Thanks, Calvin [PATCH v4 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list [PATCH v4 2/2] mpt2sas: Refcount fw_events and fix unsafe list usage Total diffstat: drivers/scsi/mpt2sas/mpt2sas_base.h | 22 +- drivers/scsi/mpt2sas/mpt2sas_scsih.c | 592 ++- drivers/scsi/mpt2sas/mpt2sas_transport.c | 12 +- 3 files changed, 451 insertions(+), 175 deletions(-) Diff showing changes v3 => v4: http://jcalvinowens.github.io/stuff/mpt2sas-patchset-v3v4.patch Diff showing changes v2 => v3: http://jcalvinowens.github.io/stuff/mpt2sas-patchset-v2v3.patch Diff showing changes v1 => v2: http://jcalvinowens.github.io/stuff/mpt2sas-patchset-v1v2.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] sched/nohz: Affine unpinned timers to housekeepers
From: Vatika Harlalka
The problem addressed in this patch is about affining unpinned timers.
Adaptive or Full Dynticks CPUs are currently disturbed by unnecessary
jitter due to firing of such timers on them.
This patch will affine timers to online CPUs which are not full dynticks
in NOHZ_FULL configured systems. It should not introduce overhead in
nohz full off case due to static keys.
Reviewed-by: Preeti U Murthy
Signed-off by: Vatika Harlalka
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Christoph Lameter
Cc: Thomas Gleixner
Cc: Paul E. McKenney
Cc: Chris Metcalf
Signed-off-by: Frederic Weisbecker
---
include/linux/tick.h | 9 -
kernel/sched/core.c | 7 +--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 3741ba1..51e6493 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -143,13 +143,20 @@ static inline void tick_nohz_full_add_cpus_to(struct
cpumask *mask)
if (tick_nohz_full_enabled())
cpumask_or(mask, mask, tick_nohz_full_mask);
}
-
+static inline int housekeeping_any_cpu(void)
+{
+ return cpumask_any_and(housekeeping_mask, cpu_online_mask);
+}
extern void __tick_nohz_full_check(void);
extern void tick_nohz_full_kick(void);
extern void tick_nohz_full_kick_cpu(int cpu);
extern void tick_nohz_full_kick_all(void);
extern void __tick_nohz_task_switch(struct task_struct *tsk);
#else
+static inline int housekeeping_any_cpu(void)
+{
+ return smp_processor_id();
+}
static inline bool tick_nohz_full_enabled(void) { return false; }
static inline bool tick_nohz_full_cpu(int cpu) { return false; }
static inline void tick_nohz_full_add_cpus_to(struct cpumask *mask) { }
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9917c96..4fd42e4 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -623,18 +623,21 @@ int get_nohz_timer_target(void)
int i, cpu = smp_processor_id();
struct sched_domain *sd;
- if (!idle_cpu(cpu))
+ if (!idle_cpu(cpu) && is_housekeeping_cpu(cpu))
return cpu;
rcu_read_lock();
for_each_domain(cpu, sd) {
for_each_cpu(i, sched_domain_span(sd)) {
- if (!idle_cpu(i)) {
+ if (!idle_cpu(i) && is_housekeeping_cpu(cpu)) {
cpu = i;
goto unlock;
}
}
}
+
+ if (!is_housekeeping_cpu(cpu))
+ cpu = housekeeping_any_cpu();
unlock:
rcu_read_unlock();
return cpu;
--
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 1/2] mpt2sas: Refcount sas_device objects and fix unsafe list usage
On Monday 08/10 at 18:45 +0530, Sreekanth Reddy wrote:
> On Sat, Aug 1, 2015 at 10:32 AM, Calvin Owens wrote:
Sreekanth,
Thanks for the review, responses below. I'll have a v4 out shortly.
Calvin
> > These objects can be referenced concurrently throughout the driver, we
> > need a way to make sure threads can't delete them out from under each
> > other. This patch adds the refcount, and refactors the code to use it.
> >
> > Additionally, we cannot iterate over the sas_device_list without
> > holding the lock, or we risk corrupting random memory if items are
> > added or deleted as we iterate. This patch refactors _scsih_probe_sas()
> > to use the sas_device_list in a safe way.
> >
> > Cc: Christoph Hellwig
> > Cc: Bart Van Assche
> > Cc: Joe Lawrence
> > Signed-off-by: Calvin Owens
> > ---
> > Changes in v3:
> > * Drop the sas_device_lock while enabling devices, and leave the
> > sas_device object on the list, since it may need to be looked up
> > there while it is being enabled.
> > * Drop put() in _scsih_add_device(), because the ->hostdata now
> > keeps a
> > reference (this was an oversight in v2).
> > * Be consistent about calling sas_device_put() while holding the
> > sas_device_lock where feasible.
> > * Take and assert_spin_locked() on the sas_device_lock from the
> > newly
> > added __get_sdev_from_target(), add wrapper similar to other
> > lookups
> > for callers which do not explicitly take the lock.
> >
> > Changes in v2:
> > * Squished patches 1-3 into this one
> > * s/BUG_ON(!spin_is_locked/assert_spin_locked/g
> > * Store a pointer to the sas_device object in ->hostdata, to
> > eliminate
> > the need for several lookups on the lists.
> >
> > drivers/scsi/mpt2sas/mpt2sas_base.h | 22 +-
> > drivers/scsi/mpt2sas/mpt2sas_scsih.c | 467
> > +--
> > drivers/scsi/mpt2sas/mpt2sas_transport.c | 12 +-
> > 3 files changed, 348 insertions(+), 153 deletions(-)
> >
> > diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h
> > b/drivers/scsi/mpt2sas/mpt2sas_base.h
> > index caff8d1..78f41ac 100644
> > --- a/drivers/scsi/mpt2sas/mpt2sas_base.h
> > +++ b/drivers/scsi/mpt2sas/mpt2sas_base.h
> > @@ -238,6 +238,7 @@
> > * @flags: MPT_TARGET_FLAGS_XXX flags
> > * @deleted: target flaged for deletion
> > * @tm_busy: target is busy with TM request.
> > + * @sdev: The sas_device associated with this target
> > */
> > struct MPT2SAS_TARGET {
> > struct scsi_target *starget;
> > @@ -248,6 +249,7 @@ struct MPT2SAS_TARGET {
> > u32 flags;
> > u8 deleted;
> > u8 tm_busy;
> > + struct _sas_device *sdev;
> > };
> >
> >
> > @@ -376,8 +378,24 @@ struct _sas_device {
> > u8 phy;
> > u8 responding;
> > u8 pfa_led_on;
> > + struct kref refcount;
> > };
> >
> > +static inline void sas_device_get(struct _sas_device *s)
> > +{
> > + kref_get(>refcount);
> > +}
> > +
> > +static inline void sas_device_free(struct kref *r)
> > +{
> > + kfree(container_of(r, struct _sas_device, refcount));
> > +}
> > +
> > +static inline void sas_device_put(struct _sas_device *s)
> > +{
> > + kref_put(>refcount, sas_device_free);
> > +}
> > +
> > /**
> > * struct _raid_device - raid volume link list
> > * @list: sas device list
> > @@ -1095,7 +1113,9 @@ struct _sas_node
> > *mpt2sas_scsih_expander_find_by_handle(struct MPT2SAS_ADAPTER *
> > u16 handle);
> > struct _sas_node *mpt2sas_scsih_expander_find_by_sas_address(struct
> > MPT2SAS_ADAPTER
> > *ioc, u64 sas_address);
> > -struct _sas_device *mpt2sas_scsih_sas_device_find_by_sas_address(
> > +struct _sas_device *mpt2sas_get_sdev_by_addr(
> > +struct MPT2SAS_ADAPTER *ioc, u64 sas_address);
> > +struct _sas_device *__mpt2sas_get_sdev_by_addr(
> > struct MPT2SAS_ADAPTER *ioc, u64 sas_address);
> >
> > void mpt2sas_port_enable_complete(struct MPT2SAS_ADAPTER *ioc);
> > diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> > b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> > index 3f26147..a2af9a5 100644
> > --- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> > +++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c
> > @@ -526,8 +526,61 @@ _scsih_determine_boot_device(struct MPT2SAS_ADAPTER
> > *ioc,
> > }
> > }
> >
> > +static struct _sas_device *
> > +__mpt2sas_get_sdev_from_target(struct MPT2SAS_ADAPTER *ioc,
> > + struct MPT2SAS_TARGET *tgt_priv)
> > +{
> > + struct _sas_device *ret;
> > +
> > + assert_spin_locked(>sas_device_lock);
> > +
> > + ret = tgt_priv->sdev;
> > + if (ret)
> > + sas_device_get(ret);
> > +
> > + return ret;
> > +}
> > +
> > +static struct _sas_device *
> > +mpt2sas_get_sdev_from_target(struct MPT2SAS_ADAPTER *ioc,
> > + struct MPT2SAS_TARGET *tgt_priv)
> > +{
> > + struct _sas_device
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 6:32 PM, Stas Sergeev wrote: > 14.08.2015 04:21, Andy Lutomirski пишет: > >> On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote: >>> >>> 14.08.2015 03:27, Linus Torvalds пишет: On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote: > > For example because you can as well do: > prctl(ARCH_SET_SIGNAL_SS, 0) > which will mean "restore ss in sighandler to its current value", I really think a prctl() is the wrong thing to do. If you want a signal handler to save/restore segments, I think it should be a SA_xyz flag to sigaction() (the way we have SA_RESTART >>> >>> Yes, I was proposing the new sigaction() flag in this thread >>> already too. But at the end, prctl() looks better to me because >>> it allows to pass the TLS value to use when restoring FS. >>> The thing is that I am trying to find the similar treatment for >>> both the SS and FS problems. If you don't think they need a >>> similar treatment, then perhaps the Andy's patch is enough. >>> etc). And off by default because of the obvious compatibility issues. >>> >>> Of course. >>> >>> So, what we have right now (in the latest Andy's patch) is: >>> 1. lar heuristics >>> 2. new uc_flags flag >>> >>> What it solves: dosemu's regression. >>> >>> What prctl() can give: >>> - fix to dosemu's regression >>> - fix to the TLS problem in the future >>> - no hack and heuristics >>> >>> With SA_xyz you can only solve the SS problem, so it is >>> probably not any better than the uc_flags things coded >>> up by Andy. >> >> I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. > > Stop right here, doesn't the SA_xyz allow to avoid the > lar heuristic? Why would you still need the lar heuristic then? > Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and > the lar heuristic is gone. The LAR heuristic is about five lines of code, and it makes signal delivery more reliable. Sure, we could gate the "regs->ss = __USER_DS" line on a flag, but why? > >> Unfortunately, I don't think we were clever enough to allow this to be >> probed easily -- we silently ignore unrecognized sa_flags bits. > > Big deal, check the kversion. :) Not so good. For example, if you made your DOSEMU patch to use the saved SS check the version, then the backported revert would break you. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] Drivers: hv: vmbus: fix init_vp_index() for reloading hv_netvsc
> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Thursday, August 13, 2015 4:09 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> Dexuan Cui
> Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: fix init_vp_index() for reloading
> hv_netvsc
>
> On Thu, 2015-08-13 at 17:07 -0700, K. Y. Srinivasan wrote:
> > From: Dexuan Cui
> >
> > This fixes the recent commit 3b71107d73b16074afa7658f3f0fcf837aabfe24:
>
> Which tree is this in? upstream linus is giving me bad object on that
> id.
Greg's char-misc tree.
>
>
> > Drivers: hv: vmbus: Further improve CPU affiliation logic
> >
> > Without the fix, reloading hv_netvsc hangs the guest.
>
> The reason for looking for the commit id was to see if cc to stable was
> necessary, is it?
The offending patch was committed on August 5th and cc to stable was not
necessary.
K. Y
>
> James
>
> > Signed-off-by: Dexuan Cui
> > Signed-off-by: K. Y. Srinivasan
> > ---
> > drivers/hv/channel_mgmt.c | 17 +
> > 1 files changed, 17 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> > index 3ab4753..8a4105c 100644
> > --- a/drivers/hv/channel_mgmt.c
> > +++ b/drivers/hv/channel_mgmt.c
> > @@ -204,6 +204,8 @@ void hv_process_channel_removal(struct
> vmbus_channel *channel, u32 relid)
> > spin_lock_irqsave(_connection.channel_lock, flags);
> > list_del(>listentry);
> > spin_unlock_irqrestore(_connection.channel_lock,
> flags);
> > +
> > + primary_channel = channel;
> > } else {
> > primary_channel = channel->primary_channel;
> > spin_lock_irqsave(_channel->lock, flags);
> > @@ -211,6 +213,14 @@ void hv_process_channel_removal(struct
> vmbus_channel *channel, u32 relid)
> > primary_channel->num_sc--;
> > spin_unlock_irqrestore(_channel->lock, flags);
> > }
> > +
> > + /*
> > +* We need to free the bit for init_vp_index() to work in the case
> > +* of sub-channel, when we reload drivers like hv_netvsc.
> > +*/
> > + cpumask_clear_cpu(channel->target_cpu,
> > + _channel->alloced_cpus_in_node);
> > +
> > free_channel(channel);
> > }
> >
> > @@ -457,6 +467,13 @@ static void init_vp_index(struct vmbus_channel
> *channel, const uuid_le *type_gui
> > continue;
> > }
> >
> > + /*
> > +* NOTE: in the case of sub-channel, we clear the sub-channel
> > +* related bit(s) in primary->alloced_cpus_in_node in
> > +* hv_process_channel_removal(), so when we reload
> drivers
> > +* like hv_netvsc in SMP guest, here we're able to re-allocate
> > +* bit from primary->alloced_cpus_in_node.
> > +*/
> > if (!cpumask_test_cpu(cur_cpu,
> > >alloced_cpus_in_node)) {
> > cpumask_set_cpu(cur_cpu,
>
>
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
14.08.2015 04:21, Andy Lutomirski пишет: On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote: 14.08.2015 03:27, Linus Torvalds пишет: On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote: For example because you can as well do: prctl(ARCH_SET_SIGNAL_SS, 0) which will mean "restore ss in sighandler to its current value", I really think a prctl() is the wrong thing to do. If you want a signal handler to save/restore segments, I think it should be a SA_xyz flag to sigaction() (the way we have SA_RESTART Yes, I was proposing the new sigaction() flag in this thread already too. But at the end, prctl() looks better to me because it allows to pass the TLS value to use when restoring FS. The thing is that I am trying to find the similar treatment for both the SS and FS problems. If you don't think they need a similar treatment, then perhaps the Andy's patch is enough. etc). And off by default because of the obvious compatibility issues. Of course. So, what we have right now (in the latest Andy's patch) is: 1. lar heuristics 2. new uc_flags flag What it solves: dosemu's regression. What prctl() can give: - fix to dosemu's regression - fix to the TLS problem in the future - no hack and heuristics With SA_xyz you can only solve the SS problem, so it is probably not any better than the uc_flags things coded up by Andy. I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. Stop right here, doesn't the SA_xyz allow to avoid the lar heuristic? Why would you still need the lar heuristic then? Just call it SA_RESTORE_SS instead of SA_SAVE_SS, and the lar heuristic is gone. Unfortunately, I don't think we were clever enough to allow this to be probed easily -- we silently ignore unrecognized sa_flags bits. Big deal, check the kversion. :) Unforunately, in my eyes SA_xyz doesn't help with FS, so whether it is better than uc_flags or not, is not what I care about. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 5:50 PM, Stas Sergeev wrote: > 14.08.2015 03:27, Linus Torvalds пишет: >> >> On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote: >>> >>> For example because you can as well do: >>> prctl(ARCH_SET_SIGNAL_SS, 0) >>> which will mean "restore ss in sighandler to its current value", >> >> I really think a prctl() is the wrong thing to do. >> >> If you want a signal handler to save/restore segments, I think it >> should be a SA_xyz flag to sigaction() (the way we have SA_RESTART > > Yes, I was proposing the new sigaction() flag in this thread > already too. But at the end, prctl() looks better to me because > it allows to pass the TLS value to use when restoring FS. > The thing is that I am trying to find the similar treatment for > both the SS and FS problems. If you don't think they need a > similar treatment, then perhaps the Andy's patch is enough. > >> etc). And off by default because of the obvious compatibility issues. > > Of course. > > So, what we have right now (in the latest Andy's patch) is: > 1. lar heuristics > 2. new uc_flags flag > > What it solves: dosemu's regression. > > What prctl() can give: > - fix to dosemu's regression > - fix to the TLS problem in the future > - no hack and heuristics > > With SA_xyz you can only solve the SS problem, so it is > probably not any better than the uc_flags things coded > up by Andy. I'm leaning slightly toward LAR heuristic + SA_SAVE_SS. Using a sigaction flag is a bit less weird than using uc_flags. It's also kind of nice that it's more composable -- you can install a SIGUSR1 handler that's just normal code and set SA_SAVE_SS and it'll work, whereas with uc_flags you need to explicitly twiddle uc_flags in the handler. Unfortunately, I don't think we were clever enough to allow this to be probed easily -- we silently ignore unrecognized sa_flags bits. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] crypto: KEYS: convert public key to the akcipher API
On Thu, Aug 13, 2015 at 03:23:16PM +0100, David Howells wrote: > > > - /* Decode the public key */ > > - ret = asn1_ber_decoder(_rsakey_decoder, ctx, > > - ctx->key, ctx->key_size); > > - if (ret < 0) > > + cert->pub->key = kmemdup(ctx->key, ctx->key_size, GFP_KERNEL); > > + if (!cert->pub->key) > > goto error_decode; > > The generic public key code should *not* see the container wrappings (ASN.1 > from an X.509 cert in this case). The public key could be supplied by OpenPGP > instead, for example, or directly by a driver. No in this case it's fine because the format of our key input specification just happens to coincide with the input here. 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/
i915/kasan: out of bounds access in i915_cmd_parser_init_ring
I finally got around to playing with kasan. It didn't end well. I added some debugging to validate_cmds_sorted to print out the table sizes right before the stack traces. Dave validate_cmds_sorted: table:a1fb4220 cmd_table_count:3 validate_cmds_sorted: table:a1fb4220 table->count:12 validate_cmds_sorted: table:a1fb4230 table->count:20 validate_cmds_sorted: table:a1fb4230 table->count:20 validate_cmds_sorted: table:a1fb4240 table->count:18 validate_cmds_sorted: table:a1fb41e0 cmd_table_count:2 validate_cmds_sorted: table:a1fb41e0 table->count:12 validate_cmds_sorted: table:a1fb41f0 table->count:7 validate_cmds_sorted: table:a1fb4100 cmd_table_count:3 validate_cmds_sorted: table:a1fb4100 table->count:12 validate_cmds_sorted: table:a1fb4110 table->count:6 == BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x66b/0x760 at addr a1fb4374 Read of size 4 by task swapper/0/1 Address belongs to variable hsw_blt_cmds+0xb4/0xe0 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4 0002 8801d6baf478 a1c0b4fb 0032 8801d6baf510 8801d6baf4f8 a123198f 8801d6baf5a8 ed003ad75e9b 0246 a1fb4110 1000 Call Trace: [] dump_stack+0x4f/0x7b [] kasan_report_error+0x3bf/0x3f0 [] kasan_report+0x3b/0x40 [] ? i915_cmd_parser_init_ring+0x66b/0x760 [] __asan_load4+0x66/0xa0 [] i915_cmd_parser_init_ring+0x66b/0x760 [] intel_init_ring_buffer+0x449/0x680 [] intel_init_blt_ring_buffer+0x38e/0x520 [] i915_gem_init_rings+0x74/0x220 [] i915_gem_init+0x1e2/0x320 [] i915_driver_load+0x1571/0x2310 [] ? debug_lockdep_rcu_enabled+0x4e/0x70 [] ? __lock_acquire+0x97e/0x2710 [] ? debug_smp_processor_id+0x17/0x20 [] ? debug_show_all_locks+0x280/0x280 [] ? __mutex_unlock_slowpath+0x11b/0x1e0 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] ? i915_getparam+0x390/0x390 [] ? mark_held_locks+0xa4/0xd0 [] ? _raw_spin_unlock_irqrestore+0x58/0x70 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] ? preempt_count_sub+0xc1/0x130 [] ? _raw_spin_unlock_irqrestore+0x43/0x70 [] drm_dev_register+0xd1/0x170 [] drm_get_pci_dev+0xf1/0x350 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] i915_pci_probe+0x83/0xb0 [] pci_device_probe+0xcf/0x130 [] driver_probe_device+0x1e1/0x410 [] ? driver_probe_device+0x410/0x410 [] ? driver_probe_device+0x410/0x410 [] __driver_attach+0xd6/0xe0 [] bus_for_each_dev+0xf5/0x160 [] ? bus_remove_file+0xa0/0xa0 [] ? do_raw_spin_unlock+0xa4/0x140 [] ? preempt_count_sub+0xc1/0x130 [] driver_attach+0x30/0x40 [] bus_add_driver+0x2b1/0x330 [] driver_register+0xde/0x1b0 [] __pci_register_driver+0xbc/0xd0 [] drm_pci_init+0x1e7/0x210 [] ? do_one_initcall+0x108/0x242 [] ? do_one_initcall+0x108/0x242 [] i915_init+0xdb/0xe3 [] ? mipi_dsi_bus_init+0x12/0x12 [] do_one_initcall+0x227/0x242 [] ? start_kernel+0x4ed/0x4ed [] ? parse_args+0x5b/0x4f0 [] kernel_init_freeable+0x290/0x321 [] ? rest_init+0x150/0x150 [] kernel_init+0x14/0x100 [] ? rest_init+0x150/0x150 [] ret_from_fork+0x3f/0x70 [] ? rest_init+0x150/0x150 Memory state around the buggy address: a1fb4200: fa fa fa fa 00 00 00 00 00 00 fa fa fa fa fa fa a1fb4280: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00 >a1fb4300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa ^ a1fb4380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 a1fb4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == == BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x67e/0x760 at addr a1fb4378 Read of size 4 by task swapper/0/1 Address belongs to variable hsw_blt_cmds+0xb8/0xe0 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4 0002 8801d6baf478 a1c0b4fb 0032 8801d6baf510 8801d6baf4f8 a123198f 0010 ed00 0246 fbfff43f686e 66201000 Call Trace: [] dump_stack+0x4f/0x7b [] kasan_report_error+0x3bf/0x3f0 [] kasan_report+0x3b/0x40 [] ? i915_cmd_parser_init_ring+0x67e/0x760 [] __asan_load4+0x66/0xa0 [] i915_cmd_parser_init_ring+0x67e/0x760 [] intel_init_ring_buffer+0x449/0x680 [] intel_init_blt_ring_buffer+0x38e/0x520 [] i915_gem_init_rings+0x74/0x220 [] i915_gem_init+0x1e2/0x320 [] i915_driver_load+0x1571/0x2310 [] ? debug_lockdep_rcu_enabled+0x4e/0x70 [] ? __lock_acquire+0x97e/0x2710 [] ? debug_smp_processor_id+0x17/0x20 [] ? debug_show_all_locks+0x280/0x280 [] ? __mutex_unlock_slowpath+0x11b/0x1e0 [] ? trace_hardirqs_on_caller+0x192/0x2a0 [] ? i915_getparam+0x390/0x390 [] ? mark_held_locks+0xa4/0xd0 [] ?
[PATCH v2] scripts/setlocalversion: fix false positive -dirty tag from ctime
git-diff-index cannot detect that a file hasn't actually changed when the file's ctime has changed (e.g. if chmod was used but didn't actually result in any changes), which was causing setlocalversion to incorrectly add a -dirty tag. Run git-update-index beforehand to make sure that the index is correct. Test prep: make defconfig && make prepare Before, starting from clean index: $ ls -l Kbuild -rw-rw-r-- 1 gregory gregory 2622 Aug 10 12:38 Kbuild $ chmod u+w Kbuild # intentional no-op that updates ctime $ CONFIG_LOCALVERSION_AUTO=y /bin/sh scripts/setlocalversion $PWD -00130-g7ddab73-dirty After, starting from clean index: $ ls -l Kbuild -rw-rw-r-- 1 gregory gregory 2622 Aug 10 12:38 Kbuild $ chmod u+w Kbuild # intentional no-op that updates ctime $ CONFIG_LOCALVERSION_AUTO=y /bin/sh scripts/setlocalversion $PWD -00131-gfa3477d Signed-off-by: Gregory Fong --- I sent this a few months ago[1] but didn't really include enough info about how to reproduce the problem. This is indeed probably a very unusual issue for someone to have, but sometimes people write braindead scripts that do things like update ctime for no reason, and it can be really hard to track down why the kernel build gets marked as '-dirty' when there aren't any modifications to the tree if you're not intimately familiar with the difference between git's plumbing and porcelain commands. [1] https://lkml.org/lkml/2015/3/10/793 scripts/setlocalversion | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/setlocalversion b/scripts/setlocalversion index 63d91e2..4ba52fc 100755 --- a/scripts/setlocalversion +++ b/scripts/setlocalversion @@ -45,6 +45,9 @@ scm_version() # Check for git and a git repo. if test -z "$(git rev-parse --show-cdup 2>/dev/null)" && head=`git rev-parse --verify --short HEAD 2>/dev/null`; then + # In case ctime has changed but there are not actually any + # changes that would be committed. + git update-index -q --refresh # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore # it, because this version is defined in the top level Makefile. -- 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 net-next 1/7] net: dsa: add support for switchdev VLAN objects
On Thu, Aug 13, 2015 at 05:01:57PM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> On 15-08-13 22:16:08, Andrew Lunn wrote:
> > On Thu, Aug 13, 2015 at 12:52:17PM -0400, Vivien Didelot wrote:
> > > Add new functions in DSA drivers to access hardware VLAN entries through
> > > SWITCHDEV_OBJ_PORT_VLAN objects:
> > >
> > > - port_pvid_get() and vlan_getnext() to dump a VLAN
> > > - port_vlan_del() to exclude a port from a VLAN
> > > - port_pvid_set() and port_vlan_add() to join a port to a VLAN
> > >
> > > The DSA infrastructure will ensure that each VLAN of the given range
> > > does not already belong to another bridge. If it does, it will fallback
> > > to software VLAN and won't program the hardware.
> > >
> > > Signed-off-by: Vivien Didelot
> > > ---
> > > include/net/dsa.h | 11
> > > net/dsa/slave.c | 158
> > > ++
> > > 2 files changed, 169 insertions(+)
> > >
> > > diff --git a/include/net/dsa.h b/include/net/dsa.h
> > > index 6356f43..bd9b765 100644
> > > --- a/include/net/dsa.h
> > > +++ b/include/net/dsa.h
> > > @@ -298,6 +298,17 @@ struct dsa_switch_driver {
> > > u8 state);
> > >
> > > /*
> > > + * VLAN support
> > > + */
> > > + int (*port_pvid_get)(struct dsa_switch *ds, int port, u16 *pvid);
> > > + int (*port_pvid_set)(struct dsa_switch *ds, int port, u16 pvid);
> > > + int (*port_vlan_add)(struct dsa_switch *ds, int port, u16 vid,
> > > + bool untagged);
> > > + int (*port_vlan_del)(struct dsa_switch *ds, int port, u16 vid);
> > > @@ -794,6 +949,9 @@ static const struct net_device_ops
> > > dsa_slave_netdev_ops = {
> > > .ndo_netpoll_cleanup= dsa_slave_netpoll_cleanup,
> > > .ndo_poll_controller= dsa_slave_poll_controller,
> > > #endif
> > > + .ndo_bridge_getlink = switchdev_port_bridge_getlink,
> > > + .ndo_bridge_setlink = switchdev_port_bridge_setlink,
> > > + .ndo_bridge_dellink = switchdev_port_bridge_dellink,
> > > };
> >
> > Do these changes belong here?
>
> Yes, these are used by switchdev to access bridge requests and exchange
> SWITCHDEV_OBJ_PORT_VLAN objects with DSA, through the its switchdev_ops.
O.K, so if a v2 is needed, please mention this in the change log. It
was not obvious to me.
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/5] clk: core: add CLK_OPS_PARENT_ON flags to support clocks require parent on
On 07/28, Dong Aisheng wrote: > On Freescale i.MX7D platform, all clocks operations, including > enable/disable, rate change and re-parent, requires its parent > clock on. Current clock core can not support it well. > This patch introduce a new flag CLK_OPS_PARENT_ON to handle this > special case in clock core that enable its parent clock firstly for > each operation and disable it later after operation complete. > > This patch fixes disaling clocks while its parent is off. > This is a special case that is caused by a state mis-align between > HW and SW in clock tree during booting. > Usually in uboot, we may enable all clocks in HW by default. > And during kernel booting time, the parent clock could be disabled in its > driver probe due to calling clk_prepare_enable and clk_disable_unprepare. > Because it's child clock is only enabled in HW while its SW usecount > in clock tree is still 0, so clk_disable of parent clock will gate > the parent clock in both HW and SW usecount ultimately. > Then there will be a clock is on in HW while its parent is disabled. > > Later when clock core does clk_disable_unused, this clock disable > will cause system hang due to the limitation of operation requiring > its parent clock on. > > Cc: Mike Turquette > Cc: Stephen Boyd > Signed-off-by: Dong Aisheng > --- Sorry, I still don't agree with this patch. There's no reason we should be turning on clocks during late init so that we can turn off clocks. If there's some sort of problem in doing that we should figure it out and make it so that during late init we turn off clocks from the leaves of the tree to the root. I agree that there's a problem here where we don't properly handle keeping children clocks on if a driver comes in and turns off a clock in the middle of the tree before late init. That's a real bug, and we should fix it. Mike Turquette has been doing some work to have a way to indicate that certain clocks should be kept on until client drivers grab them. I think it will also make sure to up refcounts on parent clocks in the middle of the tree when it figures out that a child clock is enabled. Would that be all that we need to do to fix this problem? Also, the subject of this patch and patch 5 are the same. Why? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v10 3/8] add fpga manager core
Hi Alan, I've updated my Zynq driver (it can be found in an older version against your v8 in the Xilinx tree, too) https://github.com/mfischer/linux/tree/alan-fpga-mgr-v10 to use your v10 version of the patch. Either I'm using the API wrong , or it never gets to the 'operating state'. Comments inline below. On Thu, Aug 13, 2015 at 10:37 AM, wrote: > From: Alan Tull > > API to support programming FPGA. > > The following functions are exported as GPL: > * fpga_mgr_buf_load >Load fpga from image in buffer > > * fpga_mgr_firmware_load >Request firmware and load it to the FPGA. > > * fpga_mgr_register > * fpga_mgr_unregister >FPGA device drivers can be added by calling >fpga_mgr_register() to register a set of >fpga_manager_ops to do device specific stuff. > > * of_fpga_mgr_get > * fpga_mgr_put >Get/put a reference to a fpga manager. > > The following sysfs files are created: > * /sys/class/fpga_manager//name > Name of low level driver. > > * /sys/class/fpga_manager//state > State of fpga manager > > Signed-off-by: Alan Tull > Acked-by: Michal Simek > --- > v2: s/mangager/manager/ > check for invalid request_nr > add fpga reset interface > rework the state code > remove FPGA_MGR_FAIL flag > add _ERR states to fpga manager states enum > low level state op now returns a state enum value > initialize framework state from driver state op > remove unused fpga read stuff > merge sysfs.c into fpga-mgr.c > move suspend/resume from bus.c to fpga-mgr.c > > v3: Add struct device to fpga_manager (not as a pointer) > Add to_fpga_manager > Don't get irq in fpga-mgr.c (let low level driver do it) > remove from struct fpga_manager: nr, np, parent > get rid of fpga_mgr_get_new_minor() > simplify fpga_manager_register: > reorder parameters > use dev instead of pdev > get rid of code that used to make more sense when this > was a char driver, don't alloc_chrdev_region > use a mutex instead of flags > > v4: Move to drivers/staging > > v5: Make some things be static > Kconfig: add 'if FPGA' > Makefile: s/fpga-mgr-core.o/fpga-mgr.o/ > clean up includes > use enum fpga_mgr_states instead of int > static const char *state_str > use DEVICE_ATTR_RO/RW/WO and ATTRIBUTE_GROUPS > return -EINVAL instead of BUG_ON > move ida_simple_get after kzalloc > clean up fpga_mgr_remove > fpga-mgr.h: remove '#if IS_ENABLED(CONFIG_FPGA)' > add kernel-doc documentation > Move header to new include/linux/fpga folder > static const struct fpga_mgr_ops > dev_info msg simplified > > v6: no statically allocated string for image_name > kernel doc fixes > changes regarding enabling SYSFS for fpga mgr > Makefile cleanup > > v7: no change in this patch for v7 of the patchset > > v8: no change in this patch for v8 of the patchset > > v9: remove writable attributes 'firmware' and 'reset' > remove suspend/resume support for now > remove list of fpga managers; use class device iterators instead > simplify locking by giving out only one ref exclusively > add device tree support > add flags > par down API into fewer functions > update copyright year > rename some functions for clarity > clean up unnecessary #includes > add some error messages > write_init may need to look at buffer header, so add to params > > v10: Make this a tristate in Kconfig > pass flags parameter to write_complete > use BIT(0) in macro > move to drivers/fpga > fpga_manager_get/put call module_try_get/module_put > --- > drivers/Kconfig |2 + > drivers/Makefile |1 + > drivers/fpga/Kconfig | 14 ++ > drivers/fpga/Makefile |8 + > drivers/fpga/fpga-mgr.c | 381 > + > include/linux/fpga/fpga-mgr.h | 127 ++ > 6 files changed, 533 insertions(+) > create mode 100644 drivers/fpga/Kconfig > create mode 100644 drivers/fpga/Makefile > create mode 100644 drivers/fpga/fpga-mgr.c > create mode 100644 include/linux/fpga/fpga-mgr.h > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 6e973b8..2683346 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -184,4 +184,6 @@ source "drivers/android/Kconfig" > > source "drivers/nvdimm/Kconfig" > > +source "drivers/fpga/Kconfig" > + > endmenu > diff --git a/drivers/Makefile b/drivers/Makefile > index b64b49f..832a6e0 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/ > obj-$(CONFIG_THUNDERBOLT) += thunderbolt/ > obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/ > obj-$(CONFIG_ANDROID) += android/ > +obj-$(CONFIG_FPGA) += fpga/ > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > new file mode 100644 > index 000..f1f1f6d > --- /dev/null > +++ b/drivers/fpga/Kconfig >
[PATCH] security/smack/smack_lsm.c: Fix build error when CONFIG_SECURITY_SMACK_BRINGUP is not defined
This change fixes the following build error when
CONFIG_SECURITY_SMACK_BRINGUP is not defined:
security/smack/smack_lsm.c: In function ‘smack_parse_opts_str’:
security/smack/smack_lsm.c:618:26: error: ‘tokens’ undeclared (first use in
this function)
token = match_token(p, tokens, args);
^
security/smack/smack_lsm.c:618:26: note: each undeclared identifier is reported
only once for each function it appears in
The above has been introduced by commit
3bf2789cad9e6573dc19a6c3d123c2c049f2d90f "smack: allow mount opts setting over
filesystems with binary mount data".
Signed-off-by: Murilo Opsfelder Araujo
---
security/smack/smack_lsm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 54fb3a1..6201907 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -57,14 +57,6 @@ LIST_HEAD(smk_ipv6_port_list);
static struct kmem_cache *smack_inode_cache;
int smack_enabled;
-#ifdef CONFIG_SECURITY_SMACK_BRINGUP
-static char *smk_bu_mess[] = {
- "Bringup Error",/* Unused */
- "Bringup", /* SMACK_BRINGUP_ALLOW */
- "Unconfined Subject", /* SMACK_UNCONFINED_SUBJECT */
- "Unconfined Object",/* SMACK_UNCONFINED_OBJECT */
-};
-
static const match_table_t tokens = {
{Opt_fsdefault, SMK_FSDEFAULT "%s"},
{Opt_fsfloor, SMK_FSFLOOR "%s"},
@@ -74,6 +66,14 @@ static const match_table_t tokens = {
{Opt_error, NULL},
};
+#ifdef CONFIG_SECURITY_SMACK_BRINGUP
+static char *smk_bu_mess[] = {
+ "Bringup Error",/* Unused */
+ "Bringup", /* SMACK_BRINGUP_ALLOW */
+ "Unconfined Subject", /* SMACK_UNCONFINED_SUBJECT */
+ "Unconfined Object",/* SMACK_UNCONFINED_OBJECT */
+};
+
static void smk_bu_mode(int mode, char *s)
{
int i = 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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
14.08.2015 03:27, Linus Torvalds пишет: On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote: For example because you can as well do: prctl(ARCH_SET_SIGNAL_SS, 0) which will mean "restore ss in sighandler to its current value", I really think a prctl() is the wrong thing to do. If you want a signal handler to save/restore segments, I think it should be a SA_xyz flag to sigaction() (the way we have SA_RESTART Yes, I was proposing the new sigaction() flag in this thread already too. But at the end, prctl() looks better to me because it allows to pass the TLS value to use when restoring FS. The thing is that I am trying to find the similar treatment for both the SS and FS problems. If you don't think they need a similar treatment, then perhaps the Andy's patch is enough. etc). And off by default because of the obvious compatibility issues. Of course. So, what we have right now (in the latest Andy's patch) is: 1. lar heuristics 2. new uc_flags flag What it solves: dosemu's regression. What prctl() can give: - fix to dosemu's regression - fix to the TLS problem in the future - no hack and heuristics With SA_xyz you can only solve the SS problem, so it is probably not any better than the uc_flags things coded up by Andy. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 5:24 PM, Andy Lutomirski wrote: > > So yes, it mostly works. It also sucks, and it makes it extremely > unpleasant for any other program to do this. Well, I'd argue that (a) we don't really _want_ any other programs to do that (b) but yeah, we might want to make it easier to do cleanly and explicitly for dosemu (and any other possible programs that do want to do it) so if this is for just things like dosemu and for test applications etc, let's just introduce something like SA_RESTORE_SS for those to explicitly opt in to "I want this signal handler to save and restore SS". That's how we have handled these kinds of things in the past (ie SA_SIGINFO extends the stack frame with siginfo, sa_restorer says that user space will use its own sigrestore function, etc etc). Yeah, the SA_xyzzy flags aren't exactly _common_, but it's how we've handled these kinds of compat issues in the past (SA_ONESHOT, SA_MASK, and SA_NOCLDWAIT are obviously about the traditional BSD/SysV differences, and SA_RESTORER is a Linux internal compatibility thing etc) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mtd: add SMEM parser for QCOM platforms
On 08/13/2015 02:33 PM, Mathieu Olivari wrote:
diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c
new file mode 100644
index 000..6cbf610
--- /dev/null
+++ b/drivers/mtd/qcom_smem_part.c
+#define SMEM_PARTS_MAX 32
+
+struct smem_partition {
+ char name[SMEM_PART_NAME_SZ];
+ uint32_t start;
+ uint32_t size;
+ uint32_t attr;
Is this little endian? __le32? I think so.
+};
+
+struct smem_partition_table {
+ uint32_t magic[2];
+ uint32_t version;
+ uint32_t len;
Same for these being little endian. And if so, please make magic into a
byte array of size 8 and then do a memcmp with another static byte array.
+ struct smem_partition parts[SMEM_PARTS_MAX];
+};
+
+static int qcom_smem_get_flash_blksz(uint64_t **smem_blksz)
I don't know, but I prefer u64 because it's short and sweet. But I'm not
the maintainer here.
+{
+ int ret;
+ size_t size;
+
+ ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_BLOCK_SIZE,
+ (void **) smem_blksz, );
Is the cast necessary?
+
+ if (ret < 0) {
+ pr_err("Unable to read flash blksz from SMEM\n");
+ return -ENOENT;
+ }
+
+ if (size != sizeof(**smem_blksz)) {
+ pr_err("Invalid flash blksz size in SMEM\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int qcom_smem_get_flash_type(uint64_t **smem_flash_type)
+{
+ int ret;
+ size_t size;
+
+ ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_TYPE,
+ (void **) smem_flash_type, );
+
+ if (ret < 0) {
+ pr_err("Unable to read flash type from SMEM\n");
+ return -ENOENT;
+ }
+
+ if (size != sizeof(**smem_flash_type)) {
+ pr_err("Invalid flash type size in SMEM\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int qcom_smem_get_flash_partitions(struct smem_partition_table **pparts)
+{
+ int ret;
+ size_t size;
+
+ ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_AARM_PARTITION_TABLE,
+ (void **) pparts, );
+
+ if (ret < 0) {
+ pr_err("Unable to read partition table from SMEM\n");
+ return -ENOENT;
+ }
+
+ return 0;
+}
+
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+static bool is_spi_device(struct device_node *np)
+{
+ struct device *dev;
+
+ dev = bus_find_device(_bus_type, NULL, np, of_dev_node_match);
I'm pretty sure this holds a reference to the device that needs to be
released with put_device().
+ return dev ? true : false;
+}
+
+static int parse_qcom_smem_partitions(struct mtd_info *master,
+ struct mtd_partition **pparts,
+ struct mtd_part_parser_data *data)
+{
+ struct smem_partition_table *smem_parts;
+ uint64_t *smem_flash_type, *smem_blksz;
+ struct mtd_partition *mtd_parts;
+ struct device_node *of_node = data->of_node;
+ int i, ret;
+
+ /*
+* SMEM will only store the partition table of the boot device.
+* If this is not the boot device, do not return any partition.
+*/
+ ret = qcom_smem_get_flash_type(_flash_type);
+ if (ret < 0)
+ return ret;
+
+ if ((*smem_flash_type == SMEM_FLASH_NAND && !mtd_type_is_nand(master))
+ || (*smem_flash_type == SMEM_FLASH_SPI && !is_spi_device(of_node)))
+ return 0;
+
+ /*
+* Just for sanity purpose, make sure the block size in SMEM matches the
+* block size of the MTD device
+*/
+ ret = qcom_smem_get_flash_blksz(_blksz);
+ if (ret < 0)
+ return ret;
+
+ if (*smem_blksz != master->erasesize) {
+ pr_err("SMEM block size differs from MTD block size\n");
+ return -EINVAL;
+ }
+
+ /* Get partition pointer from SMEM */
+ ret = qcom_smem_get_flash_partitions(_parts);
+ if (ret < 0)
+ return ret;
+
+ if (smem_parts->magic[0] != SMEM_PTABLE_MAGIC_1 ||
+ smem_parts->magic[1] != SMEM_PTABLE_MAGIC_2) {
+ pr_err("SMEM partition magic invalid\n");
+ return -EINVAL;
+ }
+
+ /* Allocate and populate the mtd structures */
+ mtd_parts = kcalloc(smem_parts->len, sizeof(struct mtd_partition),
sizeof(*mtd_parts)?
+ GFP_KERNEL);
+ if (mtd_parts == NULL)
if (!mtd_parts) is more kernel style.
+ return -ENOMEM;
+
+ for (i = 0; i < smem_parts->len; i++) {
+ struct smem_partition *part = _parts->parts[i];
+
+ mtd_parts[i].name = part->name;
+ mtd_parts[i].size = part->size * (*smem_blksz);
+
[PATCH] iwlwifi: out-of-bounds access in iwl_init_sband_channels
Both loops of this function compare data from the 'chan' array and then
check if the index is valid.
The 2 conditions should be inverted to avoid an out-of-bounds access.
Signed-off-by: Adrien Schildknecht
---
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
index 21302b6..acc3d18 100644
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c
@@ -713,12 +713,12 @@ int iwl_init_sband_channels(struct iwl_nvm_data *data,
struct ieee80211_channel *chan = >channels[0];
int n = 0, idx = 0;
- while (chan->band != band && idx < n_channels)
+ while (idx < n_channels && chan->band != band)
chan = >channels[++idx];
sband->channels = >channels[idx];
- while (chan->band == band && idx < n_channels) {
+ while (idx < n_channels && chan->band == band) {
chan = >channels[++idx];
n++;
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 5:17 PM, Stas Sergeev wrote: > > For example because you can as well do: > prctl(ARCH_SET_SIGNAL_SS, 0) > which will mean "restore ss in sighandler to its current value", I really think a prctl() is the wrong thing to do. If you want a signal handler to save/restore segments, I think it should be a SA_xyz flag to sigaction() (the way we have SA_RESTART etc). And off by default because of the obvious compatibility issues. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds wrote: > On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote: >> 14.08.2015 02:00, Andy Lutomirski пишет: >>> >>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's >>> threading library starts using WRFSBASE instead of arch_prctl. >> >> Hmm, how about the following: >> >> prctl(ARCH_SET_SIGNAL_FS, my_tls) >> If my_tls==NULL - use current fsbase (including one of WRFSBASE). >> If my_tls==(void)-1 - don't restore. >> >> Can this work? > > I'm really inclined to wonder whether we need the change and such a flag at > all. > > Basically, no _normal_ application will ever play with segments at all > on x86-64. So our current behavior of not touching any segments at all > for signal handling would seem to be the right thing to do - because > it handles all the sane cases optimally. > > And applications that *do* play with segments very much know they do > so, and we already put the onus on *them* to save/restore segments. > That's how dosemu clearly works today. I agree for all but CS and SS, which are special. CS is fine already. The way that DOSEMU works around SS it is hideous: it just gives up on sigreturn working and fixes the segments with IRET. (Also, if DOSEMU ever wants to get ESP[31:16] right, it *can't*: only the kernel can usefully do espfix64, and DOSEMU can't get the kernel to return from 64-bit code to 16-bit code, because we zap SS. DOSEMU fudges it by forcibly zeroing ESP[31:16]), but that's not a full solution and I wouldn't be surprised if something breaks as a result. So yes, it mostly works. It also sucks, and it makes it extremely unpleasant for any other program to do this. I'd argue that keeping things like the sigreturn_64 test working is quite valuable, because it's a royal PITA to exercise this code cleanly without proper control of SS. Unfortunately, making it hard for sigreturn_64 to exercise this stuff doesn't mean that the bad guys can't do it, because they'll use malformed ELF files, or ptrace, or stupid modify_ldt races (except I hopefully fixed those), or x32, or compat, or some other hack I haven't thought of yet, and they'll hit the same bugs. I've lost count of the number of bugs of various severities that the sigreturn tests have shaken out *and* caught in patches that were emailed in. We could say "forget sigreturn_64, use sigreturn_32 instead", but that can't exercise !IA32_EMULATION kernels, and that code is a bit different. (BadIRET, for example, is nominally unreachable from 64-bit code without modify_ldt and the sigreturn fix, except that I think know of one really nasty way to do it. I have no intention of implementing that, so keeping selftests working nicely makes me *much* more confident.) Obviously, if we reintroduce SS restoration, we need to do it much more carefully. My RFC patches are an attempt to do that, but it needs a lot of care to make sure all the bases are covered. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
14.08.2015 03:05, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
and then gets #GP. You land in a signal handler. As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is. What else is the kernel supposed to shove in there?
The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---
This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?
I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.
Setting selector and base is what you call an "equivalent of
sigaltstack"?
Yes. sigaltstack says "hey, kernel! here's my SP for signal
handling." I think we'd need something similar to tell the kernel
what my_tls_base is. Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.
If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No
regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?
DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.
Hmm, how about the following:
prctl(ARCH_SET_SIGNAL_FS, my_tls)
If my_tls==NULL - use current fsbase (including one of WRFSBASE).
If my_tls==(void)-1 - don't restore.
Can this work?
Certainly, but why?
For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",
and this will fix the regression right here right now, without
any lar heuristic, and will keep the correct behaviour of always
restoring ss for those who need that.
ISTM user code should do this itself with a
little bit of asm unless there's a good reason it wouldn't work.
Any example of that asm?
I can even code up the ARCH_SET_SIGNAL_SS patch if you want,
it seems absolutely trivial, much simpler than the aforementioned asm,
much simpler than the patches you propose.
So my question is more like "why not", rather than "why".
Just because it is simple and clean, IMHO.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code
From: Linus Lüssing
Date: Thu, 13 Aug 2015 05:54:07 +0200
> The recent refactoring of the IGMP and MLD parsing code into
> ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
> BUG() invocation for bridges:
>
> I wrongly assumed that skb_get() could be used as a simple reference
> counter for an skb which is not the case. skb_get() bears additional
> semantics, a user count. This leads to a BUG() invocation in
> pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
> with a user count greater than one - unfortunately the refactoring did
> just that.
>
> Fixing this by removing the skb_get() call and changing the API: The
> caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
> additionally check whether the returned skb_trimmed is a clone.
>
> Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
> Reported-by: Brenden Blanco
> Signed-off-by: Linus Lüssing
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/3] usb: dwc2: reset AHB hclk domain before init
On 8/11/2015 12:57 AM, Yunzhi Li wrote:
> We initiate dwc2 usb controller in BIOS, when kernel driver
> start-up we should reset AHB hclk domain to reset all AHB
> interface registers to default. Without this the FIFO value
> setting might be incorrect because calculating FIFO size need the
> power-on value of GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
>
> This patch could avoid warnning massage like in rk3288 platform:
> [2.074764] dwc2 ff58.usb: 256 invalid for
> host_perio_tx_fifo_size. Check HW configuration.
>
> Signed-off-by: Yunzhi Li
> ---
>
> drivers/usb/dwc2/platform.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 9093530..ec6bf6b 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -165,6 +166,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
> struct resource *res;
> struct phy *phy;
> struct usb_phy *uphy;
> + struct reset_control *rst;
> int retval;
> int irq;
>
> @@ -189,6 +191,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
>
> hsotg->dev = >dev;
>
> + /* AHB hclk domain reset, set all AHB interface registers to default */
> + rst = devm_reset_control_get_optional(>dev, "ahb");
> + if (IS_ERR(rst)) {
> + dev_dbg(>dev, "Can't get dwc2 AHB reset\n");
> + } else {
> + reset_control_assert(rst);
> + udelay(5);
> + reset_control_deassert(rst);
> + }
> +
> /*
>* Use reasonable defaults so platforms don't have to provide these.
>*/
>
I didn't receive the other two patches in this series so I was
confused about where the "ahb_reset" was coming from when I
replied to your other patch.
I see you changed the name and documented the DT so never mind.
Another thing is that there probably shouldn't be a debug
message on the IS_ERR condition since that is the common case
and of no interest to other platforms.
The other two resets you added aren't used by the driver
anywhere right? Maybe those should be left out until they are.
John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote: > 14.08.2015 02:00, Andy Lutomirski пишет: >> >> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's >> threading library starts using WRFSBASE instead of arch_prctl. > > Hmm, how about the following: > > prctl(ARCH_SET_SIGNAL_FS, my_tls) > If my_tls==NULL - use current fsbase (including one of WRFSBASE). > If my_tls==(void)-1 - don't restore. > > Can this work? I'm really inclined to wonder whether we need the change and such a flag at all. Basically, no _normal_ application will ever play with segments at all on x86-64. So our current behavior of not touching any segments at all for signal handling would seem to be the right thing to do - because it handles all the sane cases optimally. And applications that *do* play with segments very much know they do so, and we already put the onus on *them* to save/restore segments. That's how dosemu clearly works today. So why not just keep to that policy? It has worked fairly well so far. Only when we tried to change that policy did we hit these problems, because existing applications obviously already live with what we do (or rather, what we _don't_ do) right now... Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote:
> 14.08.2015 02:00, Andy Lutomirski пишет:
>
>> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
>>>
>>> 14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
>
> 14.08.2015 01:11, Andy Lutomirski пишет:
>
>> Now suppose you set some magic flag and jump (via sigreturn,
>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>> and then gets #GP. You land in a signal handler. As far as the
>> kernel's concerned, the FS base register is whatever the base of LDT
>> entry 0 is. What else is the kernel supposed to shove in there?
>
> The same as what happens when you do in userspace:
> ---
> asm ("mov $0,%%fs\n");
> prctl(ARCH_SET_FS, my_tls_base);
> ---
>
> This was the trick I did before gcc started to use FS in prolog,
> now I have to do this in asm.
> But how simpler for the kernel is to do the same?
>
>> I think that making this work fully in the kernel would require a
>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>
> Setting selector and base is what you call an "equivalent of
> sigaltstack"?
Yes. sigaltstack says "hey, kernel! here's my SP for signal
handling." I think we'd need something similar to tell the kernel
what my_tls_base is. Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.
>>>
>>> If someone uses WRFSBASE and wants things to be preserved
>>> in a sighandler, he'll just not set the aforementioned flag. No
>>> regression.
>>> Whoever wants to use that flag properly, will not use WRFSBASE,
>>> and will use ARCH_SET_FS or set_thread_area().
>>> What exactly breakage do you have in mind?
>>
>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
>> threading library starts using WRFSBASE instead of arch_prctl.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS, my_tls)
> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
> If my_tls==(void)-1 - don't restore.
>
> Can this work?
Certainly, but why? ISTM user code should do this itself with a
little bit of asm unless there's a good reason it wouldn't work. A
good reason it wouldn't work is that high-performance applications
need this and an extra syscall is too slow, but IMO that would need
evidence.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: minor typo fix in mailbox.txt
On Mon, 3 Aug 2015 09:30:25 +0800 Leo Yan wrote: > Fix minor typo so that can pass correct pointer variable for > container_of(). Looks good to me, applied to the docs tree. I also took the opportunity to eliminate the (now) needless line-splitting on the affected lines. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Thu, Aug 13, 2015 at 4:43 PM, Stas Sergeev wrote: > In fact, in the cases I can remember, the kernel patches > were never reverted, see this for instance: > https://lkml.org/lkml/2005/3/26/21 > And there were many other breakages too, for example when > kernel started to use top-down memory allocations. These > were because of the poor code in dosemu, and dosemu was > asked to fix the code. I guess the policy to never break userspace > was not existing back then. Or there is some margin below > which the code quality is considered not worth the troubles. :) Back in 2005 we may well not have been as strict about regressions as we are now, no. The strict policy of no regressions actually originally started mainly wrt suspend/resume issues, where the "fix one machine, break another" kind of back-and-forth caused endless problems, and meant that we didn't actually necessarily make any forward progress, just moving a problem around. (That said, I'd like to think that we've _always_ tried very hard to not break stuff, it just wasn't necessarily the kind of very explicit and hard rule that it is these days). Also, there are certainly developers who push back on fixing the regressions they caused. That is in fact the cause of some of my more memorable explosions. But if I'm not brought into the discussion, and the push-back happens on a mailing list, I may not even be aware of the regression and the fact that a developer isn't willing to fix it. I've also seen other projects be more willing to work around problems like this than I personally would consider to be a good idea. For example, we had some Wine regressions that broke a steam game or two, and it was debugged on the steam and wine lists, and took a longish time to actually even get to the attention of kernel people, because the developers were actually willing to try to do an update and fix their application to not do the thing that caused problems. Which I certainly appreciate, but at the same time that doesn't necessarily help the user who sits there with a game that just didn't work. So even if an app is getting updated eventually, the kernel breakage should be fixed. So if some patch causes problems, and the author of the patch doesn't acknowledge the problem or even if the application developer says "we can work around that", always feel free to escalate the issue and bring in upper maintainers. That said, it *does* depend a bit on just how core the area is. Sometimes it just gets too painful to fix things, and while the "no regressions" rule is pretty damn close to the strictest rule we have, there are never any completely absolute rules. As mentioned, there are exceptions to the regression rule too, and sometimes the result might just end up being "very few people are actually affected, and there's a sufficiently good reason for the regression that we'll just cop out". But that should really be a very rare occurrence. We used to have quite a lot of those kinds of issues with the GPU layer (resulting in flag-days with the X server etc), and it really causes huge problems. So there are no absolutes. But regressions are a serious problem, and need to be treated as such. I will not _guarantee_ that we always fix them, but I would hope we do our best. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LOAN OFFERS AT LOW INTEREST
We give out loans at 3% interest rate and We are always ready to cater to your loan need no matter your credit background. Email us now via: royalsofi...@inbox.lv. for more Detail. Full Name,Country,Loan Amount,Duration Number.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
14.08.2015 02:00, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote:
14.08.2015 01:29, Andy Lutomirski пишет:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev wrote:
14.08.2015 01:11, Andy Lutomirski пишет:
Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
and then gets #GP. You land in a signal handler. As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is. What else is the kernel supposed to shove in there?
The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---
This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?
I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.
Setting selector and base is what you call an "equivalent of
sigaltstack"?
Yes. sigaltstack says "hey, kernel! here's my SP for signal
handling." I think we'd need something similar to tell the kernel
what my_tls_base is. Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.
If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?
DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.
Hmm, how about the following:
prctl(ARCH_SET_SIGNAL_FS, my_tls)
If my_tls==NULL - use current fsbase (including one of WRFSBASE).
If my_tls==(void)-1 - don't restore.
Can this work?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Applied "regulator: core: Spelling fix" to the regulator tree
The patch
regulator: core: Spelling fix
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d3fb9800146b7ad96b7604755c1a943fe1abbde2 Mon Sep 17 00:00:00 2001
From: Viresh Kumar
Date: Thu, 13 Aug 2015 18:09:49 +0530
Subject: [PATCH] regulator: core: Spelling fix
Trivial spell fix, s/succesfully/successfully.
Signed-off-by: Viresh Kumar
Signed-off-by: Mark Brown
---
drivers/regulator/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 62e4f3b..999a94b 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2723,7 +2723,7 @@ int regulator_set_voltage(struct regulator *regulator,
int min_uV, int max_uV)
goto out;
/* If we're trying to set a range that overlaps the current voltage,
-* return succesfully even though the regulator does not support
+* return successfully even though the regulator does not support
* changing the voltage.
*/
if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE)) {
--
2.5.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/
[RFC PATCH 0/1] i2c: scan ACPI enumerated I2C mux channels
I would like to add support for scanning I2C devices connected to ACPI
OF compatible muxes described in ASL like this:
Device (MUX0)
{
Name (_ADR, 0x70)
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate()
{
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^^SMB2", 0x00,
ResourceConsumer,,)
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "nxp,pca9548" },
}
})
// MUX channels
Device (CH00) { Name (_ADR, 0x0) }
}
Scope(MUX0.CH00)
{
Device (TMP0) {
/* Temp sensor ASL, for example. */
}
}
It seems like a reasonable way to describe a common I2C component and
kernel support is almost there.
I had to:
1) Find and set an ACPI companion for the "virtual" I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
At first, I was confused about why adap.dev->parent is used in
acpi_i2c_register_devices(). I found b34bb1ee from 4/2013 (ACPI / I2C:
Use parent's ACPI_HANDLE()), which offers an explanation.
This patch works well, but I'm not sure about the code to just fall back
to using adap.dev when adap.dev->parent doesn't have an ACPI companion.
Is there a more explicit check I can make to determine if the adapter
represents a mux channel?
Any feedback would be welcome. Thanks,
--Dustin
Dustin Byford (1):
i2c: acpi: scan ACPI enumerated I2C mux channels
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
--
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/
[RFC PATCH 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Set an ACPI companion for I2C mux channels enumerated through ACPI and
ensure they are scanned for devices.
Signed-off-by: Dustin Byford
---
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..23cc8e9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -171,8 +171,18 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
if (!adap->dev.parent)
return;
+ /*
+* Determine where to start walking the ACPI namespace. The common
+* case is to start at the adapter's parent device. However, in
+* the case of a "virtual" I2C adapter created to represent a mux
+* channel the parent dev (pointing to the mux device) does not
+* have an ACPI handle. Walk starting at the adapter instead.
+*/
handle = ACPI_HANDLE(adap->dev.parent);
if (!handle)
+ handle = ACPI_HANDLE(>dev);
+
+ if (!handle)
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..2731b99 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Now try to populate the mux adapter's ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
--
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 2/3] ARM: qcom: add SMEM device node to IPQ806x dts
On 08/13/2015 02:33 PM, Mathieu Olivari wrote:
@@ -79,6 +79,15 @@
#hwlock-cells = <1>;
};
+
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <>;
+ reg = <0x4100 0x4000>;
Does this reg property do something? I thought we were supposed to leave
this out when not using the rpm msg ram. Also, if there's no reg, it
should be at the root /.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 1/1] Documentation: describe how to add a system call
On Mon, 10 Aug 2015 09:00:44 +0100 David Drysdale wrote: > Add a document describing the process of adding a new system call, > including the need for a flags argument for future compatibility, and > covering 32-bit/64-bit concerns (albeit in an x86-centric way). This seems about ready, so I've gone ahead and applied it to the docs tree. Many thanks! jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] workqueue: fix some docbook warnings
There are some errors in the docbook comments in workqueue.h that cause
warnings when the docs are built; this only recently came to light because
these comments were not used until now. Fix the comments to make the
warnings go away.
The "args..." "fix" is a hack. kerneldoc doesn't deal properly with named
variadic arguments in macros, so all I've really achieved here is to make
it shut up. Fixing kerneldoc will have to wait for more time.
Signed-off-by: Jonathan Corbet
---
Say the word if you'd like me to keep this in the docs tree.
include/linux/workqueue.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 738b30b39b68..0197358f1e81 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -265,7 +265,7 @@ static inline unsigned int work_static(struct work_struct
*work) { return 0; }
/**
* delayed_work_pending - Find out whether a delayable work item is currently
* pending
- * @work: The work item in question
+ * @w: The work item in question
*/
#define delayed_work_pending(w) \
work_pending(&(w)->work)
@@ -366,7 +366,7 @@ __alloc_workqueue_key(const char *fmt, unsigned int flags,
int max_active,
* @fmt: printf format for the name of the workqueue
* @flags: WQ_* flags
* @max_active: max in-flight work items, 0 for default
- * @args: args for @fmt
+ * @args...: args for @fmt
*
* Allocate a workqueue with the specified parameters. For detailed
* information on WQ_* flags, please refer to Documentation/workqueue.txt.
@@ -398,7 +398,7 @@ __alloc_workqueue_key(const char *fmt, unsigned int flags,
int max_active,
* alloc_ordered_workqueue - allocate an ordered workqueue
* @fmt: printf format for the name of the workqueue
* @flags: WQ_* flags (only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful)
- * @args: args for @fmt
+ * @args...: args for @fmt
*
* Allocate an ordered workqueue. An ordered workqueue executes at
* most one work item at any given time in the queued order. They are
--
2.4.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 v4 2/4] gpio: brcmstb: Add interrupt and wakeup source support
On Thu, Aug 13, 2015 at 4:11 AM, Linus Walleij wrote:
> On Sat, Aug 1, 2015 at 3:17 AM, Gregory Fong wrote:
>
>> Uses the gpiolib irqchip helpers. For this to work, the irq setup
>> function is called once per bank instead of once per device. Note
>> that all known uses of this block have a BCM7120 L2 interrupt
>> controller as a parent. Supports interrupts for all GPIOs.
>>
>> In the IRQ handler, we check for raised IRQs for invalid GPIOs and
>> warn (ratelimited) if they're encountered.
>>
>> Also, several drivers (e.g. gpio-keys) allow for GPIOs to be
>> configured as wakeup sources, and this GPIO controller supports that
>> through a separate interrupt path.
>>
>> The de-facto standard DT property "wakeup-source" is checked, since
>> that indicates whether the GPIO controller hardware can wake. Uses
>> the IRQCHIP_MASK_ON_SUSPEND irq_chip flag because UPG GIO doesn't have
>> any of its own wakeup source configuration.
>>
>> Aside regarding gpiolib irqchip helpers: It wasn't obvious (to me)
>> that you can have multiple chained irqchips and associated IRQ domains
>> for a single parent IRQ, and as long as the xlate function is written
>> correctly, a GPIO IRQ request end up checking the correct domain and
>> will get associated with the correct IRQ. What helps make this clear
>> is to read
>> drivers/gpio/gpiolib-of.c:
>>- of_gpiochip_find_and_xlate()
>>- of_get_named_gpiod_flags()
>> drivers/gpio/gpiolib.c:
>>- gpiochip_find()
>>
>> Signed-off-by: Gregory Fong
>> ---
>> v4:
>> - when checking parent_irq, use <= 0 or > 0 since 0 is NO_IRQ.
>
> Patch applied, but:
>
>
>> + if (of_property_read_bool(np, "interrupt-controller")) {
>> + priv->parent_irq = platform_get_irq(pdev, 0);
>> + if (priv->parent_irq <= 0) {
>> + dev_err(dev, "Couldn't get IRQ");
>> + return -ENOENT;
>> + }
>> + } else {
>> + priv->parent_irq = -ENOENT;
>> + }
>> +
>> if (brcmstb_gpio_sanity_check_banks(dev, np, res))
>> return -EINVAL;
>
> This patch does not apply cleanly because the version in my
> tree has INIT_LIST_HEAD(>bank_list);
> before the sanity check.
>
> I applied it manually, but check that things are working right.
Your tree seems to be missing
commit 2252607d327d5219a6331b50e6ec266d56402be0
Author: Gregory Fong
Date: Wed Jun 17 18:00:40 2015 -0700
gpio: brcmstb: fix null ptr dereference in driver remove
which you had pulled in and sent for 4.2-rc1. It should apply cleanly
on top of that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] doc: Add more workqueue functions to the documentation
On Mon, 10 Aug 2015 15:16:16 -0700 Tim Bird wrote: > There are some workqueue functions declared in workqueue.h, so include > that in the workqueue section of the DocBook docs. Applied to the docs tree, thanks. It sure would be nice if changes like this were accompanied by a patch fixing the additional warnings it drags in ... :) In this case I've put something together for workqueue.h and will send it off shortly. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
14.08.2015 02:18, Linus Torvalds пишет: On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds wrote: The _only_ thing that matters is that something broke. To clarify: things like test programs etc don't matter. Real applications, used by real users. That's what regressions cover. If you have a workflow that isn't just some random kernel test thing, and you depend on it, and we break it, the kernel is supposed to fix it. There are some (very few) exceptions. If it's a security issue, we may not be able to "fix" it, because other concerns can obviously take precedence. Also, sometimes the reports come in way too late - if you were running some stable distro kernel for several years, and updated, and notice a change that happened four years ago and modern applications now rely on the _new_ behavior, we may not be able to fix the regression any more. But no, "it was an unintentional kernel bug and clearly just stupid crap code, and we fixed it and now the kernel is much better and cleaner" is not a valid reason for regressions. We'll go back to the stupid and crap code if necessary, however much that may annoy us. IMHO at least such ocasions should be listed somewhere, and the software authors should be asked to fix their code. Then you'll be able to re-visit the problem later. It may be unreasonable to carry the compatibility hacks forever if the software that needed it, released the fix 10 years ago. In fact, in the cases I can remember, the kernel patches were never reverted, see this for instance: https://lkml.org/lkml/2005/3/26/21 And there were many other breakages too, for example when kernel started to use top-down memory allocations. These were because of the poor code in dosemu, and dosemu was asked to fix the code. I guess the policy to never break userspace was not existing back then. Or there is some margin below which the code quality is considered not worth the troubles. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
