[PATCH] brd: expose number of allocated pages in debugfs

[Kyle McMartin]

From: Calvin Owens 

While the maximum size of each ramdisk is defined either
as a module parameter, or compile time default, it's impossible
to know how many pages have currently been allocated by each
ram%d device, since they're allocated when used and never freed.

This patch creates a new directory at this location:

/sys/kernel/debug/ramdisk_pages/

...which will contain a file named "ram%d" for each instantiated
ramdisk on the system. The file is read-only, and read() will
output the number of pages currently held by that ramdisk.

Signed-off-by: Calvin Owens 
[cleaned up the !CONFIG_DEBUG_FS case and API changes for HEAD]
Signed-off-by: Kyle McMartin 
---
 drivers/block/brd.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 2723a70eb855..39b9d6aee5b8 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -48,6 +49,7 @@ struct brd_device {
 */
spinlock_t  brd_lock;
struct radix_tree_root  brd_pages;
+   u64 brd_nr_pages;
 };
 
 /*
@@ -116,6 +118,8 @@ static struct page *brd_insert_page(struct brd_device *brd, 
sector_t sector)
page = radix_tree_lookup(>brd_pages, idx);
BUG_ON(!page);
BUG_ON(page->index != idx);
+   } else {
+   brd->brd_nr_pages++;
}
spin_unlock(>brd_lock);
 
@@ -369,11 +373,13 @@ __setup("ramdisk_size=", ramdisk_size);
  */
 static LIST_HEAD(brd_devices);
 static DEFINE_MUTEX(brd_devices_mutex);
+static struct dentry *brd_debugfs_dir;
 
 static struct brd_device *brd_alloc(int i)
 {
struct brd_device *brd;
struct gendisk *disk;
+   char buf[DISK_NAME_LEN];
 
brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
@@ -386,6 +392,11 @@ static struct brd_device *brd_alloc(int i)
if (!brd->brd_queue)
goto out_free_dev;
 
+   snprintf(buf, DISK_NAME_LEN, "ram%d", i);
+   if (!IS_ERR_OR_NULL(brd_debugfs_dir))
+   debugfs_create_u64(buf, 0444, brd_debugfs_dir,
+  >brd_nr_pages);
+
/* This is so fdisk will align partitions on 4k, because of
 * direct_access API needing 4k alignment, returning a PFN
 * (This is only a problem on very small devices <= 4M,
@@ -401,7 +412,7 @@ static struct brd_device *brd_alloc(int i)
disk->fops  = _fops;
disk->private_data  = brd;
disk->flags = GENHD_FL_EXT_DEVT;
-   sprintf(disk->disk_name, "ram%d", i);
+   strlcpy(disk->disk_name, buf, DISK_NAME_LEN);
set_capacity(disk, rd_size * 2);
brd->brd_queue->backing_dev_info->capabilities |= 
BDI_CAP_SYNCHRONOUS_IO;
 
@@ -516,6 +527,8 @@ static int __init brd_init(void)
 
brd_check_and_reset_par();
 
+   brd_debugfs_dir = debugfs_create_dir("ramdisk_pages", NULL);
+
for (i = 0; i < rd_nr; i++) {
brd = brd_alloc(i);
if (!brd)
@@ -541,6 +554,8 @@ static int __init brd_init(void)
return 0;
 
 out_free:
+   debugfs_remove_recursive(brd_debugfs_dir);
+
list_for_each_entry_safe(brd, next, _devices, brd_list) {
list_del(>brd_list);
brd_free(brd);
@@ -555,6 +570,8 @@ static void __exit brd_exit(void)
 {
struct brd_device *brd, *next;
 
+   debugfs_remove_recursive(brd_debugfs_dir);
+
list_for_each_entry_safe(brd, next, _devices, brd_list)
brd_del_one(brd);
 
-- 
2.26.2

Re: [PATCH v2 1/1] cavium: Add firmware for CNN55XX crypto driver.

[Kyle McMartin]

On Fri, Jun 23, 2017 at 04:22:54PM +0530, Srikanth Jampala wrote:
> This patchset adds the firmware for CNN55XX cryto driver,
> supports Symmetric crypto operations.
> 
> The version of the firmware is v07.
> 
> Signed-off-by: Srikanth Jampala 

applied, sorry for the delay, i was on holidays.

--kyle

Re: [PATCH v2 1/1] cavium: Add firmware for CNN55XX crypto driver.

[Kyle McMartin]

On Fri, Jun 23, 2017 at 04:22:54PM +0530, Srikanth Jampala wrote:
> This patchset adds the firmware for CNN55XX cryto driver,
> supports Symmetric crypto operations.
> 
> The version of the firmware is v07.
> 
> Signed-off-by: Srikanth Jampala 

applied, sorry for the delay, i was on holidays.

--kyle

Re: [PATCH 1/1] cavium: Add firmware for CNN55XX crypto driver.

[Kyle McMartin]

On Fri, Jun 16, 2017 at 07:52:26PM +0530, Srikanth Jampala wrote:
> This patchset adds the firmware for CNN55XX cryto driver,
> supports Symmetric crypto operations.
> 
> The version of the firmware is v07.
> 
> Signed-off-by: Srikanth Jampala 
> ---
>  WHENCE|   9 +
>  cnn55xx_se.fw | Bin 0 -> 27698 bytes

any chance i could convince you to put this in a cavium/ subdirectory?

--kyle

Re: [PATCH 1/1] cavium: Add firmware for CNN55XX crypto driver.

[Kyle McMartin]

On Fri, Jun 16, 2017 at 07:52:26PM +0530, Srikanth Jampala wrote:
> This patchset adds the firmware for CNN55XX cryto driver,
> supports Symmetric crypto operations.
> 
> The version of the firmware is v07.
> 
> Signed-off-by: Srikanth Jampala 
> ---
>  WHENCE|   9 +
>  cnn55xx_se.fw | Bin 0 -> 27698 bytes

any chance i could convince you to put this in a cavium/ subdirectory?

--kyle

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Sun, May 28, 2017 at 05:29:23PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Kindly pull the new firmware from the following URL.
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

Pulled, thanks Ganesh.

> Thanks
> Ganesh
> 
> The following changes since commit c990aae817a1606a1fbeb0b4aac00f93dfce0e32:
> 
>   cxgb4: update firmware to revision 1.16.45.0. (2017-05-28 04:17:45 -0700)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> for you to fetch changes up to c990aae817a1606a1fbeb0b4aac00f93dfce0e32:
> 
>   cxgb4: update firmware to revision 1.16.45.0. (2017-05-28 04:17:45 -0700)
> 
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Sun, May 28, 2017 at 05:29:23PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Kindly pull the new firmware from the following URL.
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

Pulled, thanks Ganesh.

> Thanks
> Ganesh
> 
> The following changes since commit c990aae817a1606a1fbeb0b4aac00f93dfce0e32:
> 
>   cxgb4: update firmware to revision 1.16.45.0. (2017-05-28 04:17:45 -0700)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> for you to fetch changes up to c990aae817a1606a1fbeb0b4aac00f93dfce0e32:
> 
>   cxgb4: update firmware to revision 1.16.45.0. (2017-05-28 04:17:45 -0700)
> 
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Apr 26, 2017 at 08:06:53PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Kindly pull the new firmware from the following URL.
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> Thanks,
> Ganesh
> 
> The following changes since commit 766da91d4831792540451403ad349e2ece368f84:
> 
>   cxgb4: update firmware to revision 1.16.43.0 (2017-04-26 07:17:50 -0700)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

Pulled, thanks Ganesh.

regards, Kyle

> for you to fetch changes up to 766da91d4831792540451403ad349e2ece368f84:
> 
>   cxgb4: update firmware to revision 1.16.43.0 (2017-04-26 07:17:50 -0700)
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Apr 26, 2017 at 08:06:53PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Kindly pull the new firmware from the following URL.
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> Thanks,
> Ganesh
> 
> The following changes since commit 766da91d4831792540451403ad349e2ece368f84:
> 
>   cxgb4: update firmware to revision 1.16.43.0 (2017-04-26 07:17:50 -0700)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

Pulled, thanks Ganesh.

regards, Kyle

> for you to fetch changes up to 766da91d4831792540451403ad349e2ece368f84:
> 
>   cxgb4: update firmware to revision 1.16.43.0 (2017-04-26 07:17:50 -0700)
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Mon, Feb 27, 2017 at 08:01:51PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Kindly ignore my previous firmware pull-request for revision 1.16.26.0, 
> As we have some critical issues fixed in revision 1.16.33.0, please pull
> from the following URL
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream-1.16.33.0 
> 

Pulled. Thanks Ganesh.

regards, Kyle

> The following changes since commit 5abb924a730b5ecca489dfc2ebbdfc90af6ec62d:
> 
>   cxgb4: update firmware to revision 1.16.33.0 (2017-02-27 06:02:58 -0800)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream-1.16.33.0
> 
> for you to fetch changes up to 5abb924a730b5ecca489dfc2ebbdfc90af6ec62d:
> 
>   cxgb4: update firmware to revision 1.16.33.0 (2017-02-27 06:02:58 -0800)
> 
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Mon, Feb 27, 2017 at 08:01:51PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Kindly ignore my previous firmware pull-request for revision 1.16.26.0, 
> As we have some critical issues fixed in revision 1.16.33.0, please pull
> from the following URL
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream-1.16.33.0 
> 

Pulled. Thanks Ganesh.

regards, Kyle

> The following changes since commit 5abb924a730b5ecca489dfc2ebbdfc90af6ec62d:
> 
>   cxgb4: update firmware to revision 1.16.33.0 (2017-02-27 06:02:58 -0800)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream-1.16.33.0
> 
> for you to fetch changes up to 5abb924a730b5ecca489dfc2ebbdfc90af6ec62d:
> 
>   cxgb4: update firmware to revision 1.16.33.0 (2017-02-27 06:02:58 -0800)
> 
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Jan 04, 2017 at 06:19:48PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Could you please pull from the following URL?
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

applied, thanks Ganesh.

> 
> The following changes since commit f6a068e7d9885c1abbabed4ad9f58aaf15341fe9:
> 
>   cxgb4: Update firmware to revision 1.16.26.0. (2017-01-04 04:26:08 -0800)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> for you to fetch changes up to f6a068e7d9885c1abbabed4ad9f58aaf15341fe9:
> 
>   cxgb4: Update firmware to revision 1.16.26.0. (2017-01-04 04:26:08 -0800)
> 
> 
> 

Re: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Jan 04, 2017 at 06:19:48PM +0530, Ganesh Goudar wrote:
> Hi,
> 
> Could you please pull from the following URL?
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

applied, thanks Ganesh.

> 
> The following changes since commit f6a068e7d9885c1abbabed4ad9f58aaf15341fe9:
> 
>   cxgb4: Update firmware to revision 1.16.26.0. (2017-01-04 04:26:08 -0800)
> 
> are available in the git repository at:
> 
>   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> for you to fetch changes up to f6a068e7d9885c1abbabed4ad9f58aaf15341fe9:
> 
>   cxgb4: Update firmware to revision 1.16.26.0. (2017-01-04 04:26:08 -0800)
> 
> 
> 

Re: [PATCH linux-firmware 00/12] Fix metadata for linux-firmware

[Kyle McMartin]

On Sun, Sep 18, 2016 at 02:58:07AM +0100, Ben Hutchings wrote:
> This series adds a metadata consistency check script, fixes all the
> errors it found, and adds a reference to it in README.
> 
> If I don't hear any objections, I'll apply these changes next week.
> 
> Ben.

lgtm.

Re: [PATCH linux-firmware 00/12] Fix metadata for linux-firmware

[Kyle McMartin]

On Sun, Sep 18, 2016 at 02:58:07AM +0100, Ben Hutchings wrote:
> This series adds a metadata consistency check script, fixes all the
> errors it found, and adds a reference to it in README.
> 
> If I don't hear any objections, I'll apply these changes next week.
> 
> Ben.

lgtm.

Re: [PATCH 1/1] linux-firmware: Update AMD microcode patch firmware

[Kyle McMartin]

On Thu, Mar 17, 2016 at 01:56:11AM -0500, Sherry Hurwitz wrote:
> For AMD Family 15h Processors to fix bugs in prior microcode patch
> file: amd-ucode/microcode_amd_fam15h.bin
> md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 
> 
> Version: 2016_03_16
> 
> Signed-off-by: Sherry Hurwitz 

applied, thanks sherry.

regards, --kyle

Re: [PATCH 1/1] linux-firmware: Update AMD microcode patch firmware

[Kyle McMartin]

On Thu, Mar 17, 2016 at 01:56:11AM -0500, Sherry Hurwitz wrote:
> For AMD Family 15h Processors to fix bugs in prior microcode patch
> file: amd-ucode/microcode_amd_fam15h.bin
> md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 
> 
> Version: 2016_03_16
> 
> Signed-off-by: Sherry Hurwitz 

applied, thanks sherry.

regards, --kyle

Re: [PATCH] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Tue, Sep 15, 2015 at 02:54:37PM -0400, Murali Karicheri wrote:
> This patch adds firmware for Keystone QMSS Accumulator PDSP. This is required
> to support Accumulator queues. Accumulator queues are one of the queue types
> supported in drivers/soc/ti/knav_qmss_acc.c. This queue can be part of a
> channel that supports one queue or multiple queue per channel and are managed
> by the Accumulator PDSP. For more details on hardware, please refer
> http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and DT documentation below in
> linux kernel source tree
> 
> Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
> 
> Signed-off-by: Murali Karicheri 

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] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Tue, Sep 15, 2015 at 02:54:37PM -0400, Murali Karicheri wrote:
> This patch adds firmware for Keystone QMSS Accumulator PDSP. This is required
> to support Accumulator queues. Accumulator queues are one of the queue types
> supported in drivers/soc/ti/knav_qmss_acc.c. This queue can be part of a
> channel that supports one queue or multiple queue per channel and are managed
> by the Accumulator PDSP. For more details on hardware, please refer
> http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and DT documentation below in
> linux kernel source tree
> 
> Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
> 
> Signed-off-by: Murali Karicheri 

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] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Mon, Sep 21, 2015 at 11:07:20AM -0400, Murali Karicheri wrote:
> On 09/19/2015 08:53 AM, Kyle McMartin wrote:
> >On Fri, Sep 18, 2015 at 11:43:02AM -0400, Murali Karicheri wrote:> >>+
> >>Dear firmware maintainer,
> >>
> >>Could you please review this patch and comment if it requires any change? If
> >>looks good, let me know when this will be queued for merge to the mainline
> >>linux-firmware.git repo.
> >>
> >>Thanks
> >
> >I'm travelling this weekend without access to my kernel.org keys, so
> >it'll have to wait until I return.
> >
> >regards, --Kyle
> Thanks Kyle.
> 

Everything looks fine with the submission... the licence text pretty
closely matches the terms of the existing LICENSE.ti-connectivity... any
chance we could get this released under that exact license to save
redundant proliferation of license terms?

regards, --Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Mon, Sep 21, 2015 at 11:07:20AM -0400, Murali Karicheri wrote:
> On 09/19/2015 08:53 AM, Kyle McMartin wrote:
> >On Fri, Sep 18, 2015 at 11:43:02AM -0400, Murali Karicheri wrote:> >>+
> >>Dear firmware maintainer,
> >>
> >>Could you please review this patch and comment if it requires any change? If
> >>looks good, let me know when this will be queued for merge to the mainline
> >>linux-firmware.git repo.
> >>
> >>Thanks
> >
> >I'm travelling this weekend without access to my kernel.org keys, so
> >it'll have to wait until I return.
> >
> >regards, --Kyle
> Thanks Kyle.
> 

Everything looks fine with the submission... the licence text pretty
closely matches the terms of the existing LICENSE.ti-connectivity... any
chance we could get this released under that exact license to save
redundant proliferation of license terms?

regards, --Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Fri, Sep 18, 2015 at 11:43:02AM -0400, Murali Karicheri wrote:> >>+
> Dear firmware maintainer,
> 
> Could you please review this patch and comment if it requires any change? If
> looks good, let me know when this will be queued for merge to the mainline
> linux-firmware.git repo.
> 
> Thanks

I'm travelling this weekend without access to my kernel.org keys, so
it'll have to wait until I return.

regards, --Kyle

> 
> -- 
> Murali Karicheri
> Linux Kernel, Keystone
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] linux-firmware: Add qmss accumulator pdsp firmware for keystone SoCs

[Kyle McMartin]

On Fri, Sep 18, 2015 at 11:43:02AM -0400, Murali Karicheri wrote:> >>+
> Dear firmware maintainer,
> 
> Could you please review this patch and comment if it requires any change? If
> looks good, let me know when this will be queued for merge to the mainline
> linux-firmware.git repo.
> 
> Thanks

I'm travelling this weekend without access to my kernel.org keys, so
it'll have to wait until I return.

regards, --Kyle

> 
> -- 
> Murali Karicheri
> Linux Kernel, Keystone
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] README: clarify redistribution requirements covering patents

[Kyle McMartin]

On Thu, Jun 11, 2015 at 06:02:56PM -0700, Luis R. Rodriguez wrote:
> On Thu, May 28, 2015 at 5:48 PM, Luis R. Rodriguez  wrote:
> > On Tue, May 19, 2015 at 1:22 PM, Luis R. Rodriguez
> >  wrote:
> >> This v2 just changes "licence" to "license" as requested by Arend.
> >
> > Please let me know if there is anything else needed.
> 
> Just a friendly reminder.
> 

Pulled, sorry.

--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] README: clarify redistribution requirements covering patents

[Kyle McMartin]

On Thu, Jun 11, 2015 at 06:02:56PM -0700, Luis R. Rodriguez wrote:
 On Thu, May 28, 2015 at 5:48 PM, Luis R. Rodriguez mcg...@suse.com wrote:
  On Tue, May 19, 2015 at 1:22 PM, Luis R. Rodriguez
  mcg...@do-not-panic.com wrote:
  This v2 just changes licence to license as requested by Arend.
 
  Please let me know if there is anything else needed.
 
 Just a friendly reminder.
 

Pulled, sorry.

--Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RFD] linux-firmware key arrangement for firmware signing

[Kyle McMartin]

On Wed, May 20, 2015 at 09:04:26AM -0500, Seth Forshee wrote:
> I raised the question of key revocation when we discussed this on irc,
> but it wasn't answered to my satisfaction. If a key signed by the
> kernel-embedded key is compromised, how can that key be revoked so that
> it is no longer trusted?
> 
> Someone mentioned UEFI blacklists, which I don't know much about, but
> not all systems have UEFI. The only reliable option that comes to mind
> for me is an in-kernel blacklist of keys which should no longer be
> trusted.
> 

I think the solution here is two-fold... first, we'll probably try some
to use a HSM for signing, so there's extremely low risk of compromise.
Secondly, if we annotate the key such that it can only be used for
firmware, a compromise of my key won't allow you to kexec or load kernel
modules.

regards, --Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFD] linux-firmware key arrangement for firmware signing

[Kyle McMartin]

On Wed, May 20, 2015 at 09:04:26AM -0500, Seth Forshee wrote:
 I raised the question of key revocation when we discussed this on irc,
 but it wasn't answered to my satisfaction. If a key signed by the
 kernel-embedded key is compromised, how can that key be revoked so that
 it is no longer trusted?
 
 Someone mentioned UEFI blacklists, which I don't know much about, but
 not all systems have UEFI. The only reliable option that comes to mind
 for me is an in-kernel blacklist of keys which should no longer be
 trusted.
 

I think the solution here is two-fold... first, we'll probably try some
to use a HSM for signing, so there's extremely low risk of compromise.
Secondly, if we annotate the key such that it can only be used for
firmware, a compromise of my key won't allow you to kexec or load kernel
modules.

regards, --Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH resend] README: clarify redistribution requirements covering patents

[Kyle McMartin]

On Tue, May 19, 2015 at 01:18:14PM -0700, Luis R. Rodriguez wrote:
> >>   Your commit should include an update to the WHENCE file clearly
> >>   identifying the licence under which the firmware is available, and
> >> -that it is redistributable. If the licence is long and involved, it's
> >> +that it is redistributable. Being redistributable includes ensuring
> >> +the firmware license provided includes an implicit or explicit
> >> +patent grant to end users to ensure full functionality of device
> >> +operation with the firmware. If the licence is long and involved, it's
> >
> >
> > Just nitpicking here, but there is 'license' and 'licence' being used here.
> > Better stick to one and preferably 'license'.
> 
> Fixed, will submit a v2.
> 

Heh, it doesn't help that we now have LICENSE.* and LICENCE.* in the
tree as well. :/ I believe, at least in my Commonwealth english, that
licence is the file, and license is the action of licensing. I should
probably rename the LICENSE.* files in the tree to match.

--Kyle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH resend] README: clarify redistribution requirements covering patents

[Kyle McMartin]

On Tue, May 19, 2015 at 01:18:14PM -0700, Luis R. Rodriguez wrote:
Your commit should include an update to the WHENCE file clearly
identifying the licence under which the firmware is available, and
  -that it is redistributable. If the licence is long and involved, it's
  +that it is redistributable. Being redistributable includes ensuring
  +the firmware license provided includes an implicit or explicit
  +patent grant to end users to ensure full functionality of device
  +operation with the firmware. If the licence is long and involved, it's
 
 
  Just nitpicking here, but there is 'license' and 'licence' being used here.
  Better stick to one and preferably 'license'.
 
 Fixed, will submit a v2.
 

Heh, it doesn't help that we now have LICENSE.* and LICENCE.* in the
tree as well. :/ I believe, at least in my Commonwealth english, that
licence is the file, and license is the action of licensing. I should
probably rename the LICENSE.* files in the tree to match.

--Kyle

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Mar 25, 2015 at 02:16:02PM +0530, Hariprasad S wrote:
> Hariprasad Shenai (1):
>   cxgb4: update firmware to revision 1.13.32.0 for T4 and T5
> 
>  WHENCE   |   8 
>  cxgb4/t4fw-1.12.25.0.bin | Bin 518656 -> 0 bytes
>  cxgb4/t4fw-1.13.32.0.bin | Bin 0 -> 533504 bytes
>  cxgb4/t4fw.bin   |   2 +-
>  cxgb4/t5fw-1.12.25.0.bin | Bin 521216 -> 0 bytes
>  cxgb4/t5fw-1.13.32.0.bin | Bin 0 -> 581120 bytes
>  cxgb4/t5fw.bin   |   2 +-

ok, pulled... i hope you guys test forward/back compatibility with
firmware. :/

regards,
--kyle

>  7 files changed, 6 insertions(+), 6 deletions(-)
>  delete mode 100644 cxgb4/t4fw-1.12.25.0.bin
>  create mode 100644 cxgb4/t4fw-1.13.32.0.bin
>  delete mode 100644 cxgb4/t5fw-1.12.25.0.bin
>  create mode 100644 cxgb4/t5fw-1.13.32.0.bin
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Mar 25, 2015 at 02:16:02PM +0530, Hariprasad S wrote:
 Hariprasad Shenai (1):
   cxgb4: update firmware to revision 1.13.32.0 for T4 and T5
 
  WHENCE   |   8 
  cxgb4/t4fw-1.12.25.0.bin | Bin 518656 - 0 bytes
  cxgb4/t4fw-1.13.32.0.bin | Bin 0 - 533504 bytes
  cxgb4/t4fw.bin   |   2 +-
  cxgb4/t5fw-1.12.25.0.bin | Bin 521216 - 0 bytes
  cxgb4/t5fw-1.13.32.0.bin | Bin 0 - 581120 bytes
  cxgb4/t5fw.bin   |   2 +-

ok, pulled... i hope you guys test forward/back compatibility with
firmware. :/

regards,
--kyle

  7 files changed, 6 insertions(+), 6 deletions(-)
  delete mode 100644 cxgb4/t4fw-1.12.25.0.bin
  create mode 100644 cxgb4/t4fw-1.13.32.0.bin
  delete mode 100644 cxgb4/t5fw-1.12.25.0.bin
  create mode 100644 cxgb4/t5fw-1.13.32.0.bin
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 0/5] arm64: kvm: reset hyp context for kexec

[Kyle McMartin]

On Fri, Mar 27, 2015 at 03:37:04PM +, Marc Zyngier wrote:
> > [  236.260863] Kernel panic - not syncing: HYP panic:
> > [  236.260863] PS:63c9 PC:03ff0830 ESR:9606
> 
> It would be interesting if you could find out what you have at offset
> 0x830 of hyp-init.o (the stack trace is for EL1, and is not going to
> help much).
> 

Given the alignment, i'm going to assume i'm looking at the right thing:

0820 <__kvm_hyp_reset>:
 820:   d51c2000msr ttbr0_el2, x0
 824:   d5033fdfisb
 828:   d50c871ftlbialle2
 82c:   d5033f9fdsb sy
 830:   1060adr x0, 83c <__kvm_hyp_reset+0x1c>
 834:   b3403c01bfxil   x1, x0, #0, #16
 838:   d61f0020br  x1
 83c:   d53c1000mrs x0, sctlr_el2

but it seems fairly implausible to be trapping on ADR x0, 1f...

--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 0/5] arm64: kvm: reset hyp context for kexec

[Kyle McMartin]

On Thu, Mar 26, 2015 at 05:25:21PM +0900, AKASHI Takahiro wrote:
> 1) Call kvm_cpu_reset() on non-boot cpus in reboot notifier
>We don't have to do so in kexec-specific case. But the current code runs
>the function on each cpu for safety since we use a general reboot hook.
> 2) Flush D$ in kvm_cpu_reset()
>Currently doesn't do so because all the cpus are just going to shut down,
>and we actually flush D$ on boot cpu in Geoff's cpu_reset().
> 3) Compatibility with arm implementation
>Frediano[2] is no longer working on this issue on arm as he left his
>company. But my approach here is based on a generic interface and can be
>applied to arm in a similar way.
> 

i'm hitting this when rebooting with your patchset applied...

Rebooting.
[  236.260863] Kernel panic - not syncing: HYP panic:
[  236.260863] PS:63c9 PC:03ff0830 ESR:9606
[  236.260863] FAR:02800118 HPFAR:  (null) PAR:  (null)
[  236.260863] VCPU:  (null)
[  236.260863]
[  236.284440] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW   
4.0.0-0.rc5.git4.1.fc23.aarch64 #1
[  236.293734] Hardware name:  /Default string, BIOS ROD0074D 01/29/2015
[  236.300164] Call trace:
[  236.302610] [] dump_backtrace+0x0/0x150
[  236.307999] [] show_stack+0x20/0x30
[  236.313044] [] dump_stack+0x78/0x94
[  236.318086] [] panic+0xd8/0x234
[  236.322780] [] __do_kernel_fault.part.1+0x8c/0x90
[  236.329038] [] kvm_cpu_reset+0x24/0x30
[  236.334342] [] flush_smp_call_function_queue+0x88/0x178
[  236.341120] [] 
generic_smp_call_function_single_interrupt+0x14/0x20
[  236.348939] [] handle_IPI+0x1ac/0x220
[  236.354153] [] gic_handle_irq+0x88/0x90
[  236.359541] Exception stack(0xfe03db0f3e20 to 0xfe03db0f3f40)
[  236.365972] 3e20: 0001  db0f fe03 db0f3f60 fe03 
000949c0 fe00
[  236.374138] 3e40: 000ff770 fe00   fe1b0b0c fe03 
 
[  236.382304] 3e60: db158048 fe03 0001  97c9abf3 000e5f34 
e700 
[  236.390470] 3e80: db088f80 fe03 e701    
0040 
[  236.398636] 3ea0: 00448320    0001  
 
[  236.406801] 3ec0: 000c5800 fe00 90086f40 03ff   
0001 
[  236.414967] 3ee0: db0f fe03 00d406ec fe00 00d40650 fe00 
00de4000 fe00
[  236.423133] 3f00: 007a9b70 fe00 00de33a4 fe00 009baf20 fe00 
000906e0 fe00
[  236.431298] 3f20: 0100 0280 db0f3f60 fe03 000949bc fe00 
db0f3f60 fe03
[  236.439464] [] el1_irq+0x64/0xc0
[  236.444247] [] cpu_startup_entry+0x17c/0x1d0
[  236.450068] [] secondary_start_kernel+0x104/0x118
[  236.456325] CPU0: stopping
[  236.459025] CPU: 0 PID: 978 Comm: reboot Tainted: GW   
4.0.0-0.rc5.git4.1.fc23.aarch64 #1
[  236.468232] Hardware name:  /Default string, BIOS ROD0074D 01/29/2015
[  236.474660] Call trace:
[  236.477099] [] dump_backtrace+0x0/0x150
[  236.482488] [] show_stack+0x20/0x30
[  236.487529] [] dump_stack+0x78/0x94
[  236.492570] [] handle_IPI+0x1e0/0x220
[  236.497784] [] gic_handle_irq+0x88/0x90
[  236.503172] Exception stack(0xfe001869bac0 to 0xfe001869bbe0)
[  236.509602] bac0: 00d41788 fe00 fe1a4c40 fe03 1869bc00 fe00 
00135e24 fe00
[  236.517768] bae0: 0001  0004  0001  
fe1c7678 fe03
[  236.525934] bb00: 00d42880 fe00 fe144680 fe03 000f  
85ff2d66 feff02fe
[  236.534100] bb20:   86514a0f feff02fe ff7f7f7f 7f7f7fff 
01010101 01010101
[  236.542265] bb40: 0010     ff00 
 
[  236.550431] bb60: 000e2b00 fe00 87355050 03ff   
00d41788 fe00
[  236.558597] bb80: fe1a4c40 fe03 00d42000 fe00 00cf4c00 fe00 
000af928 fe00
[  236.566763] bba0:   0001  0004  
00d41000 fe00
[  236.574928] bbc0: 18698000 fe00 1869bc00 fe00 00135dfc fe00 
1869bc00 fe00
[  236.583094] [] el1_irq+0x64/0xc0
[  236.587875] [] on_each_cpu+0x3c/0x68
[  236.593003] [] kvm_reboot_notify+0x20/0x30
[  236.598655] [] notifier_call_chain+0x58/0xa0
[  236.604478] [] __blocking_notifier_call_chain+0x54/0xa0
[  236.611255] [] blocking_notifier_call_chain+0x38/0x50
[  236.617859] [] kernel_restart_prepare+0x28/0x50
[  236.623941] [] kernel_restart+0x1c/0x80
[  236.629329] [] SyS_reboot+0x13c/0x238
[  237.542991] SMP: failed to stop secondary CPUs
[  237.547426] ---[ end Kernel panic - not syncing: HYP panic:
[  237.547426] PS:63c9 PC:03ff0830 ESR:9606
[  237.547426] FAR:02800118 HPFAR:  (null) PAR:  (null)
[  237.547426] VCPU:  (null)
[  237.547426]
Boot firmware (version  built at 12:39:20 on Jan 29 2015)

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [RFC v2 0/5] arm64: kvm: reset hyp context for kexec

[Kyle McMartin]

On Fri, Mar 27, 2015 at 03:37:04PM +, Marc Zyngier wrote:
  [  236.260863] Kernel panic - not syncing: HYP panic:
  [  236.260863] PS:63c9 PC:03ff0830 ESR:9606
 
 It would be interesting if you could find out what you have at offset
 0x830 of hyp-init.o (the stack trace is for EL1, and is not going to
 help much).
 

Given the alignment, i'm going to assume i'm looking at the right thing:

0820 __kvm_hyp_reset:
 820:   d51c2000msr ttbr0_el2, x0
 824:   d5033fdfisb
 828:   d50c871ftlbialle2
 82c:   d5033f9fdsb sy
 830:   1060adr x0, 83c __kvm_hyp_reset+0x1c
 834:   b3403c01bfxil   x1, x0, #0, #16
 838:   d61f0020br  x1
 83c:   d53c1000mrs x0, sctlr_el2

but it seems fairly implausible to be trapping on ADR x0, 1f...

--Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 0/5] arm64: kvm: reset hyp context for kexec

[Kyle McMartin]

On Thu, Mar 26, 2015 at 05:25:21PM +0900, AKASHI Takahiro wrote:
 1) Call kvm_cpu_reset() on non-boot cpus in reboot notifier
We don't have to do so in kexec-specific case. But the current code runs
the function on each cpu for safety since we use a general reboot hook.
 2) Flush D$ in kvm_cpu_reset()
Currently doesn't do so because all the cpus are just going to shut down,
and we actually flush D$ on boot cpu in Geoff's cpu_reset().
 3) Compatibility with arm implementation
Frediano[2] is no longer working on this issue on arm as he left his
company. But my approach here is based on a generic interface and can be
applied to arm in a similar way.
 

i'm hitting this when rebooting with your patchset applied...

Rebooting.
[  236.260863] Kernel panic - not syncing: HYP panic:
[  236.260863] PS:63c9 PC:03ff0830 ESR:9606
[  236.260863] FAR:02800118 HPFAR:  (null) PAR:  (null)
[  236.260863] VCPU:  (null)
[  236.260863]
[  236.284440] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW   
4.0.0-0.rc5.git4.1.fc23.aarch64 #1
[  236.293734] Hardware name:  /Default string, BIOS ROD0074D 01/29/2015
[  236.300164] Call trace:
[  236.302610] [fe097770] dump_backtrace+0x0/0x150
[  236.307999] [fe0978e0] show_stack+0x20/0x30
[  236.313044] [fe771828] dump_stack+0x78/0x94
[  236.318086] [fe76fdac] panic+0xd8/0x234
[  236.322780] [fe76fcd0] __do_kernel_fault.part.1+0x8c/0x90
[  236.329038] [fe0af94c] kvm_cpu_reset+0x24/0x30
[  236.334342] [fe1362c8] flush_smp_call_function_queue+0x88/0x178
[  236.341120] [fe1364dc] 
generic_smp_call_function_single_interrupt+0x14/0x20
[  236.348939] [fe09db5c] handle_IPI+0x1ac/0x220
[  236.354153] [fe090460] gic_handle_irq+0x88/0x90
[  236.359541] Exception stack(0xfe03db0f3e20 to 0xfe03db0f3f40)
[  236.365972] 3e20: 0001  db0f fe03 db0f3f60 fe03 
000949c0 fe00
[  236.374138] 3e40: 000ff770 fe00   fe1b0b0c fe03 
 
[  236.382304] 3e60: db158048 fe03 0001  97c9abf3 000e5f34 
e700 
[  236.390470] 3e80: db088f80 fe03 e701    
0040 
[  236.398636] 3ea0: 00448320    0001  
 
[  236.406801] 3ec0: 000c5800 fe00 90086f40 03ff   
0001 
[  236.414967] 3ee0: db0f fe03 00d406ec fe00 00d40650 fe00 
00de4000 fe00
[  236.423133] 3f00: 007a9b70 fe00 00de33a4 fe00 009baf20 fe00 
000906e0 fe00
[  236.431298] 3f20: 0100 0280 db0f3f60 fe03 000949bc fe00 
db0f3f60 fe03
[  236.439464] [fe0934e4] el1_irq+0x64/0xc0
[  236.444247] [fe0ff76c] cpu_startup_entry+0x17c/0x1d0
[  236.450068] [fe09d58c] secondary_start_kernel+0x104/0x118
[  236.456325] CPU0: stopping
[  236.459025] CPU: 0 PID: 978 Comm: reboot Tainted: GW   
4.0.0-0.rc5.git4.1.fc23.aarch64 #1
[  236.468232] Hardware name:  /Default string, BIOS ROD0074D 01/29/2015
[  236.474660] Call trace:
[  236.477099] [fe097770] dump_backtrace+0x0/0x150
[  236.482488] [fe0978e0] show_stack+0x20/0x30
[  236.487529] [fe771828] dump_stack+0x78/0x94
[  236.492570] [fe09db90] handle_IPI+0x1e0/0x220
[  236.497784] [fe090460] gic_handle_irq+0x88/0x90
[  236.503172] Exception stack(0xfe001869bac0 to 0xfe001869bbe0)
[  236.509602] bac0: 00d41788 fe00 fe1a4c40 fe03 1869bc00 fe00 
00135e24 fe00
[  236.517768] bae0: 0001  0004  0001  
fe1c7678 fe03
[  236.525934] bb00: 00d42880 fe00 fe144680 fe03 000f  
85ff2d66 feff02fe
[  236.534100] bb20:   86514a0f feff02fe ff7f7f7f 7f7f7fff 
01010101 01010101
[  236.542265] bb40: 0010     ff00 
 
[  236.550431] bb60: 000e2b00 fe00 87355050 03ff   
00d41788 fe00
[  236.558597] bb80: fe1a4c40 fe03 00d42000 fe00 00cf4c00 fe00 
000af928 fe00
[  236.566763] bba0:   0001  0004  
00d41000 fe00
[  236.574928] bbc0: 18698000 fe00 1869bc00 fe00 00135dfc fe00 
1869bc00 fe00
[  236.583094] [fe0934e4] el1_irq+0x64/0xc0
[  236.587875] [fe135f14] on_each_cpu+0x3c/0x68
[  236.593003] [fe0af828] kvm_reboot_notify+0x20/0x30
[  236.598655] [fe0e0b08] notifier_call_chain+0x58/0xa0
[  236.604478] [fe0e0fe4] __blocking_notifier_call_chain+0x54/0xa0
[  236.611255] [fe0e1068] blocking_notifier_call_chain+0x38/0x50
[  236.617859] [fe0e27d0] kernel_restart_prepare+0x28/0x50
[  236.623941] [fe0e28fc] kernel_restart+0x1c/0x80
[  236.629329] [fe0e2c3c] SyS_reboot+0x13c/0x238
[  237.542991] SMP: failed to stop 

Re: [PATCH] radeon: Update Kaveri MEC firmware to #396

[Kyle McMartin]

On Sat, Mar 14, 2015 at 12:51:19AM +0200, Oded Gabbay wrote:
> This patch updates the Kaveri MEC firmware to #396 (from #391).
> The MEC firmware is mainly used for amdkfd - AMD's HSA Linux kernel driver.
> 
> Signed-off-by: Oded Gabbay 

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] radeon: Update Kaveri MEC firmware to #396

[Kyle McMartin]

On Sat, Mar 14, 2015 at 12:51:19AM +0200, Oded Gabbay wrote:
 This patch updates the Kaveri MEC firmware to #396 (from #391).
 The MEC firmware is mainly used for amdkfd - AMD's HSA Linux kernel driver.
 
 Signed-off-by: Oded Gabbay oded.gab...@amd.com

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 firmware] rtl_nic: update firmware for RTL8168H and RTL8107E

[Kyle McMartin]

On Thu, Feb 26, 2015 at 04:31:38PM +0800, Hayes Wang wrote:
> File: rtl_nic/rtl8168h-1.fw
> Version: 0.0.2
> 
> File: rtl_nic/rtl8168h-2.fw
> Version: 0.0.2
> 
> File: rtl_nic/rtl8107e-1.fw
> Version: 0.0.2
> 
> File: rtl_nic/rtl8107e-2.fw
> Version: 0.0.2
> 
> Signed-off-by: Hayes Wang 

applied, thanks very much.

regards, --Kyle

> ---
>  WHENCE|   8 
>  rtl_nic/rtl8107e-1.fw | Bin 2496 -> 992 bytes
>  rtl_nic/rtl8107e-2.fw | Bin 2464 -> 976 bytes
>  rtl_nic/rtl8168h-1.fw | Bin 2496 -> 992 bytes
>  rtl_nic/rtl8168h-2.fw | Bin 2464 -> 976 bytes
>  5 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/WHENCE b/WHENCE
> index 609b93d..b79462f 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -2188,16 +2188,16 @@ File: rtl_nic/rtl8168g-3.fw
>  Version: 0.0.1
>  
>  File: rtl_nic/rtl8168h-1.fw
> -Version: 0.0.1
> +Version: 0.0.2
>  
>  File: rtl_nic/rtl8168h-2.fw
> -Version: 0.0.1
> +Version: 0.0.2
>  
>  File: rtl_nic/rtl8107e-1.fw
> -Version: 0.0.1
> +Version: 0.0.2
>  
>  File: rtl_nic/rtl8107e-2.fw
> -Version: 0.0.1
> +Version: 0.0.2
>  
>  Licence:
>   * Copyright © 2011-2013, Realtek Semiconductor Corporation
> diff --git a/rtl_nic/rtl8107e-1.fw b/rtl_nic/rtl8107e-1.fw
> index 
> 5ac3d62bcd6adb9a28bc84dcccbccd99a0dab290..c071c2f0252b9254af81046c1f9a2996020b67a6
>  100644
> GIT binary patch
> delta 620
> zcmWlW4@gr{6vpq?a~s=m{sAo;l(cD-ZEr8PL?R->_ChKmLPDDPCoG1IwN*s4
> zNU4aLVKE{iWz>j>lwsR*M2IXilaSkpSP}6S5hFr69yoB$`F-c!`*D+%T;IYdf+2sC
> zOWe}4$>kFrqC;9MN>0h+bh(!yMSyaFQo{mALS4PSt`proK2dUslIU_fI*;{j9CWO<
> zxSQQg&60;*joFr$20I$;jOhT&8W=c(g= zck%|*s||1|4(dhfC9EqnqF(V(--MDxGwkWDNDgm9t+E}N@D99}cfzQ)U{3bJpzg*8
> zxfMEf59Z~45Y+w1h7aJQd=TY@HdLn%Av4^Ls`O!GhdZ!R>7;YJBbb$sVujj^8TmMb
> zf*(eu52fh zUxUD}!|-hg+Vl;u@mpv!-G)AK2SOr>o3-~aZXW@^`v6vJB!<1-hsZ@AAs2j%G5HCW
> z3S(fVII0RyVVz1~Rq8o-^aU!dFG>4~v=hjMl9-k!Nt;4NN+F{)YHl;?u-uh-Zn<
> z!aOyHVrU+(y$dJ~e1Z^PBr}{Imji1b{{oxkEBb{z`pw^ATl@jWf09#`oc==0{F{V-
> w$VCy1{iXRonlDk!`X}js8Fa`o1In~U2sLKZnM$FxlwrhNfz8kE8>%(`0WZl65C8xG
> 
> literal 2496
> zcmY+`aY$8J9tZH#8`lw6?5({q$7vb~2?^JE&%|{l ziHK+%iHL{@S0o~$iHMMB#F5sG2x%iCB;p|w5z$0MM1;E^o!MpPzW3qxJ?Fl2{~i
> z@ooqq^!4{NWYT~6+n+PL(lzOtOhx*ypJ!@6&(t}$aJ18w2;uLcwWWS-eeJH^FZ;jh
> z-c_5<)TNE9`Ks+Dv0+ZTN1qa$(G`WoStV*~z7!#SjW8q=;gYl#rq{eh@+~
> z`dvXT#HG1J{8KJ3F3aV|k8%ZZd9E;ioGXf- zI2TsLiQG!<3hh;~G*Kz9maELaMy{4? zEo^2Bt+cU~ZER-;J87qbPP*u3H$Cj3mp=O0%RcsVfP+K^IK*LVGQ@FCaFSD;
> z<_u>UW`t4Bah?lY z@{H%a;3cnk%^TkGj`z$Hz6l{g9{ChdND;*(DIrBEWt6jml~k~bN>)?F8mg%wO)YiQ
> z(?BEZXd=scHn5RqHqpXnw$Mr_RW}Zg$hd9(w7cpS|p3KL z<_JeQ#vnr+=L9D?#c9rPmSIL1 zp9ef-hDSUm$1HO^;VI8}?}hir2j1E$?{GJYm58lSe)U6jDSnNlHjjN*U#>U?ml-
> zqLS5Av4(1DNK;E4^)%4PI-1C`o(*iInN75?nJu)^##XkmogM6?oenzbqMP0Hu!mmy
> z=w~nc*v|nD5*gqShdIJgjxop($2q}CPH~zuoMo61MmfiME^v`cT;>W_xyBgRxxqLS
> zOmdScZgHDCOmmle+~)xgnc)$S$uY|uPk72Rp7Vm2yy7))c*{H9Gf()|{*y;O1r$<5
> zF-b~DQA!!*tY9S-tfG?DRI!F?YDiN{9rZNO$U2(HvYriWq?t{$u$e8i(#BS{v7H_4
> zq@4~r>7tw6^st9s`simb``FI`4iXvQ5QjO!QI0Xl5XU*eNltN^Gn{3Z5k@)3c`k5~
> zOI+p(SGmR**SWzs6HIcGDQ z-ZTI0;=4l3kF(wvl8M6jK`2}JPsk4Zap4^z>9hEqh>PveyTpPEU0EBS4T<4S4=98`
> zq`xTqELO#3F?6J2&6a(UxhrBNX3$2=k%r2yy{d;{? z_78lYicMwu2jy?nfmEESO2zVD=gL=?n=?=SNKL5A)S&*`xP`To)?T=d5Pn(zm-|{C
> e=Km8aLRdcW|LZpHfA{?J;<@BRc5z(z-SJ;Ub$cHG
> 
> diff --git a/rtl_nic/rtl8107e-2.fw b/rtl_nic/rtl8107e-2.fw
> index 
> 949ca670fa31242940caa9fc0e268274ae0c..76fc0544f9fb06e7e9b575a7fbb0ed00d10822b2
>  100644
> GIT binary patch
> delta 627
> zcmXw$eMnPb6vp3f*X=Sd%L5Z72*}S_s8zUkjY|#}lA7L>}Y^#W9
> z!r2E=Tda_XNEtCAB4yZil?V|vvk1A3h#3)g5j7(;po;yyu+X!+GC_H&!-nY+@9B
> 

Re: [PATCH firmware] rtl_nic: update firmware for RTL8168H and RTL8107E

[Kyle McMartin]

On Thu, Feb 26, 2015 at 04:31:38PM +0800, Hayes Wang wrote:
 File: rtl_nic/rtl8168h-1.fw
 Version: 0.0.2
 
 File: rtl_nic/rtl8168h-2.fw
 Version: 0.0.2
 
 File: rtl_nic/rtl8107e-1.fw
 Version: 0.0.2
 
 File: rtl_nic/rtl8107e-2.fw
 Version: 0.0.2
 
 Signed-off-by: Hayes Wang hayesw...@realtek.com

applied, thanks very much.

regards, --Kyle

 ---
  WHENCE|   8 
  rtl_nic/rtl8107e-1.fw | Bin 2496 - 992 bytes
  rtl_nic/rtl8107e-2.fw | Bin 2464 - 976 bytes
  rtl_nic/rtl8168h-1.fw | Bin 2496 - 992 bytes
  rtl_nic/rtl8168h-2.fw | Bin 2464 - 976 bytes
  5 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/WHENCE b/WHENCE
 index 609b93d..b79462f 100644
 --- a/WHENCE
 +++ b/WHENCE
 @@ -2188,16 +2188,16 @@ File: rtl_nic/rtl8168g-3.fw
  Version: 0.0.1
  
  File: rtl_nic/rtl8168h-1.fw
 -Version: 0.0.1
 +Version: 0.0.2
  
  File: rtl_nic/rtl8168h-2.fw
 -Version: 0.0.1
 +Version: 0.0.2
  
  File: rtl_nic/rtl8107e-1.fw
 -Version: 0.0.1
 +Version: 0.0.2
  
  File: rtl_nic/rtl8107e-2.fw
 -Version: 0.0.1
 +Version: 0.0.2
  
  Licence:
   * Copyright © 2011-2013, Realtek Semiconductor Corporation
 diff --git a/rtl_nic/rtl8107e-1.fw b/rtl_nic/rtl8107e-1.fw
 index 
 5ac3d62bcd6adb9a28bc84dcccbccd99a0dab290..c071c2f0252b9254af81046c1f9a2996020b67a6
  100644
 GIT binary patch
 delta 620
 zcmWlW4@gr{6vpq?a~s=m{sAo;l(cD-ZEr8PL?R-_ChKmLPDDPCoG1IwN*s4xnYy
 zNU4aLVKE{iWzjlwsR*M2IXilaSkpSP}6S5hFr69yoB$`F-c!`*D+%T;IYdf+2sC
 zOWe}4$kFrqC;9MN0h+bh(!yMSyaFQo{mALS4PSt`proK2dUslIU_fI*;{j9CWO
 zxSQQg60;*joFr$20I$;jOhT8W=c(g=mH1?=KF$lQRF+=wtYMiODGt#KkAsJqe
 zck%|*s||1|4(dhfC9EqnqF(V(--MDxGwkWDNDgm9t+E}N@D99}cfzQ)U{3bJpzg*8
 zxfMEf59Z~45Y+w1h7aJQd=TY@HdLn%Av4^Ls`O!GhdZ!R7;YJBbb$sVujj^8TmMb
 zf*(eu52fhT@*w~JOsURit01a$In8moCBLU4_ytw5*OglUj!SugwLAGVA?BSLj!2d
 zUxUD}!|-hg+Vl;u@mpv!-G)AK2SOro3-~aZXW@^`v6vJB!1-hsZ@AAs2j%G5HCW
 z3S(fVII0RyVVz1~Rq8o-^aU!dFG4~v=hjMl9-k!Nt;4NN+Fh{)YHl;?u-uh-Zn
 z!aOyHVrU+(y$dJ~e1Z^PBr}{Imji1b{{oxkEBb{z`pw^ATl@jWf09#`oc==0{F{V-
 w$VCy1{iXRonlDk!`X}js8Fa`o1In~U2sLKZnM$FxlwrhNfz8kE8%(`0WZl65C8xG
 
 literal 2496
 zcmY+`aY$8J9tZH#8`lw6?5({q$7vb~2?^JE%|{lk3V(NQ6j4L^+P@NJxlCL_~YW
 ziHK+%iHL{@S0o~$iHMMB#F5sG2x%iCB;p|w5z$0MM1;E^o!MpPzW3qxJ?Fl2b{~i
 z@ooqq^!4{NWYT~6+n+PL(lzOtOhx*ypJ!@6(t}$aJ18w2;uLcwWWS-eeJH^FZ;jh
 z-c_5)TNE9`KsdicDSO+Dv0+ZTN1qa$(G`WoStV*~z7!#SjW8q=;gYl#rq{eh@+~
 z`dvXT#HG1J{8KJ3F3aV|k8%ZZd9E;ioGXf-ci~m|1$2=k~sTaD*n`58WaC4i{Z!e
 zI2TsLiQG!3hh;~G*Kz9maELaMy{4?aA6-)y6PhC)djja-+OXZj!U|dU=DqQEp}v
 zEo^2Bt+cU~ZER-;J87qbPP*u3H$Cj3mp=O0%RcsVfP+K^IK*LaFk;VGQ@FCaFSD;
 z_uUW`t4Bah?lYPw*;!d0#@#vEmIFU(WQtqd_^=`sSEWz(Zzu#A9;IGRG61
 z@{H%a;3cnk%^TkGj`z$Hz6l{g9{ChdND;*(DIrBEWt6jml~k~bN)?F8mg%wO)YiQ
 z(?BEZXd=scHn5RqHqpXnw$MrTiM2TcCeFnI_RW}Zg$hd9(w7cpS|p3KLESWPn2)
 z_JeQ#vnr+=L9D?#c9rPmSIL1s9d^z(p=`nJZl78e?4N2IEXH$xWuX#cl2|0X$s
 zp9ef-hDSUm$1HO^;VI8}I?}hir2j1E$?{GJYm58lSe)U6jDSnNlHjjN*U#U?ml-
 zqLS5Av4(1DNK;E4^)%4PI-1C`o(*iInN75?nJu)^##XkmogM6?oenzbqMP0Hu!mmy
 z=w~nc*v|nD5*gqShdIJgjxop($2q}CPH~zuoMo61MmfiME^v`cT;W_xyBgRxxqLS
 zOmdScZgHDCOmmle+~)xgnc)$S$uY|uPk72Rp7Vm2yy7))c*{H9Gf()|{*y;O1r$5
 zF-b~DQA!!*tY9S-tfG?DRI!F?YDiN{9rZNO$U2(HvYriWq?t{$u$e8i(#BS{v7H_4
 zq@4~r7tw6^st9s`simb``FI`4iXvQ5QjO!QI0Xl5XU*eNltN^Gn{3Z5k@)3c`k5~
 zOI+p(SGmR**SWzs6HIcGDQC_J4|zzd)(%51HW+kI6C198Y-4GoJH;m%QRNZ+Oc)
 z-ZTI0;=4l3kF(wvl8M6jK`2}JPsk4Zap4^z9hEqhPveyTpPEU0EBS4T4S4=98`
 zq`xTqELO#3F?6J2DgTIB6a(UxhrBNX3$2=k%r2yy{d;{?q;F8PPP=~V2^rDAre
 z_78lYicMwu2jy?nfmEESO2zVD=gL=?n=?=SNKL5A)S*`xP`To)?T=d5Pn(zm-|{C
 e=Km8aLRdcW|LZpHfA{?J;@BRc5z(z-SJ;Ub$cHG
 
 diff --git a/rtl_nic/rtl8107e-2.fw b/rtl_nic/rtl8107e-2.fw
 index 
 949ca670fa31242940caa9fc0e268274ae0c..76fc0544f9fb06e7e9b575a7fbb0ed00d10822b2
  100644
 GIT binary patch
 delta 627
 zcmXw$eMnPb6vp3f*X=SdJWO%L5Z72*}S_s8zUkjYWDLA|#}lA7L}Y^#W9mtni
 z!r2E=Tda_XNEtCAB4yZil?V|vvk1A3h#3)g5j7D(;po;yyu+X!+GC_H!-nY+@9B
 zexJ)BZSLAAdnLPMm)A;iz1#uaQ=f7pq!;#V!em`9o^oJDFezNp?uGZ#;CkM?W`
 z+p8;_Zl}xL;9^Xtfc*a420Y2YXKI^BMmgIVKHqVd?N8K7taPG}|sG!du5!}Y-i
 zwFb$+I?O8TQLER%q1vgJsFzWlYe22qNWBXM2{x%El5VUqDtL{$-s8JQFg$jH(_4!
 zK+t#LtnsGz8ee5Uhw)p%mnu1opJyrxfWEU4`MRfit_X!%tYI;N^PgTok7egN3c@w
 z#X$_e9i}x+JmBWFJ07!g18?^(57VT_*vr=A5HI|oB0z!K--%U%GBUBt%~m%zBo
 zV1xZ=Rzwt4M12L1ed-JHhL2+g|}c#+yYB;6~M5jM`$*?%apP5*)%FjVy450UA6
 zgc0R2mUAOugjVUp1?AZ!0OafXpv_qvpgs53(}4u4Br87FNDr74y8B=J|oUlX4q
 zK23av_#DKEdF1^IcFhMeE$dV@kKJD(c~;t)rh{HGf8kmts#fpzgKnDjFg4o0
 zhQuEv{7EkIVC*-||ImDyY8D!|79B!vqv_Ch(OaY6^?MnTrtOR?$NJl11jTsM$
 
 literal 2464
 zcmYk;aY$8J9tZH#8^`RF~{DR$HtD5)!UGOnJu-nb@ixDgT(5$QUPE3Jr#L`1|H
 zCnBN=iHL{@35kd{A|fPOainn~A|fIpA|4_U5p6_7MA|GnxXsNhu`yd(S!d-Sfvg
 zA%rk6*jrbX`sVw;RJW%pQYVvslTqQs$N-DJ#QO!9NlqddL@YFE`(H?%jl{=IE
 zYkU7c2fyoSZ|eJguzl^?wUys|EsjBrhZjbebqPNr_r*xz6(M~PcHl_hLA%pdE`?-
 zAxVnjMHaQ`*JcNF3cq2=b5ayD3cw($mGPuncVoNOkVsllOI3%Rlh$M#_6Au@#p5E
 znE0hQhX0ntnXn{IWR_}|YA=gLi86V)TyFdoa)n$er($BNI)?EYxmK=|*dw*8aXXD
 z$c=K7+{`*!SkDGp*+?6k*vuBT(m^L(bkoBdg-H|0S4L54tBDO-9(1i!(R5Wp936Z
 zm_r=q2uC@_aZWJ8Nk%!vY0hw#bDZY_7rDe3m$||?6HIcIDXwvy8{Fg;x4FYz?s17
 

[PATCH] arm64: annotate psci invoke functions as notrace

[Kyle McMartin]

Using GCC 5 to build the kernel with ftrace enabled, we encounter the
following error as a result of the mcount prologue changing the expected
register use of the function parameters,

/tmp/cc8Kpn7A.s: Assembler messages:
/tmp/cc8Kpn7A.s:41: Error: .err encountered
/tmp/cc8Kpn7A.s:42: Error: .err encountered
/tmp/cc8Kpn7A.s:43: Error: .err encountered
/tmp/cc8Kpn7A.s:101: Error: .err encountered
/tmp/cc8Kpn7A.s:102: Error: .err encountered
/tmp/cc8Kpn7A.s:103: Error: .err encountered
scripts/Makefile.build:257: recipe for target 'arch/arm64/kernel/psci.o' failed

Fix this by annotating the function as notrace, to suppress the
generation of profiling prologues and epilogues on the function.

Signed-off-by: Kyle McMartin 

--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -113,7 +113,7 @@ static void psci_power_state_unpack(u32 power_state,
  * The following two functions are invoked via the invoke_psci_fn pointer
  * and will not be inlined, allowing us to piggyback on the AAPCS.
  */
-static noinline int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1,
+static noinline notrace int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, 
u64 arg1,
 u64 arg2)
 {
asm volatile(
@@ -128,7 +128,7 @@ static noinline int __invoke_psci_fn_hvc(u64 function_id, 
u64 arg0, u64 arg1,
return function_id;
 }
 
-static noinline int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1,
+static noinline notrace int __invoke_psci_fn_smc(u64 function_id, u64 arg0, 
u64 arg1,
 u64 arg2)
 {
asm volatile(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: annotate psci invoke functions as notrace

[Kyle McMartin]

Using GCC 5 to build the kernel with ftrace enabled, we encounter the
following error as a result of the mcount prologue changing the expected
register use of the function parameters,

/tmp/cc8Kpn7A.s: Assembler messages:
/tmp/cc8Kpn7A.s:41: Error: .err encountered
/tmp/cc8Kpn7A.s:42: Error: .err encountered
/tmp/cc8Kpn7A.s:43: Error: .err encountered
/tmp/cc8Kpn7A.s:101: Error: .err encountered
/tmp/cc8Kpn7A.s:102: Error: .err encountered
/tmp/cc8Kpn7A.s:103: Error: .err encountered
scripts/Makefile.build:257: recipe for target 'arch/arm64/kernel/psci.o' failed

Fix this by annotating the function as notrace, to suppress the
generation of profiling prologues and epilogues on the function.

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -113,7 +113,7 @@ static void psci_power_state_unpack(u32 power_state,
  * The following two functions are invoked via the invoke_psci_fn pointer
  * and will not be inlined, allowing us to piggyback on the AAPCS.
  */
-static noinline int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, u64 arg1,
+static noinline notrace int __invoke_psci_fn_hvc(u64 function_id, u64 arg0, 
u64 arg1,
 u64 arg2)
 {
asm volatile(
@@ -128,7 +128,7 @@ static noinline int __invoke_psci_fn_hvc(u64 function_id, 
u64 arg0, u64 arg1,
return function_id;
 }
 
-static noinline int __invoke_psci_fn_smc(u64 function_id, u64 arg0, u64 arg1,
+static noinline notrace int __invoke_psci_fn_smc(u64 function_id, u64 arg0, 
u64 arg1,
 u64 arg2)
 {
asm volatile(
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] linux-firmware: update firmware for Intel Broadwell SST DSP

[Kyle McMartin]

On Thu, Feb 05, 2015 at 11:27:04PM +0800, Jie Yang wrote:
> Update firmware intel/IntcSST2.bin from Version 8.4.1.68 to 8.4.1.77
> Fix for freeing capture stream just after resetting it.
> 
> Signed-off-by: Jie Yang 

applied, thanks Jie.

regards, Kyle

> ---
>  WHENCE |   1 +
>  intel/IntcSST2.bin | Bin 260256 -> 260320 bytes
>  2 files changed, 1 insertion(+)
> 
> diff --git a/WHENCE b/WHENCE
> index 7f2d6bf..6cb0778 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -2646,6 +2646,7 @@ Licence: Redistributable. See LICENCE.it913x for details
>  Driver: snd_soc_sst_acpi
>  
>  File: intel/IntcSST2.bin
> +Version: 8.4.1.77
>  
>  License: Redistributable. See LICENCE.IntcSST2 for details
>  
> diff --git a/intel/IntcSST2.bin b/intel/IntcSST2.bin
> index 
> 69ac37e78582dc5971b56eb598f43821958a9a59..e11cb61f4a00bf32a304781e3e9b1f32775285e1
>  100644
> GIT binary patch
> delta 35726
> zcmZTQ30zZ0^VuW>2oK~8w?O16AS%HV#UrQ)-guu?g3ntk+QXZpEk+R95C
> z1q3z014NXdASf!}g=a;5UU+~gf};7)CeW|_{``KAw>vv~% z>eOi^ts;SiKp^;p6Ocoyw;0_^rH9*B-$H^}w~@f{4iX$*9w7+5tNm(@$Zq{cp&-i~
> zu;DM%P9V64>qXs!wu$)?u?(R@*wd`f{Px^PfyI;vfjBQxFbm%6;XyBj0t)i!khX<)
> zE4(S_)naOdz!CB;@LsbrLJ$Gz$>9-#5%7$Mv>(9Ziv)trP__v2$vE4rXGk5S46h6Z
> z!}kWmJxFIl=}veaLRuh*k83<85EPJ_&`Jfo4P69+c7s6h1Y1i6+C3+=4T8qQP-FeH
> z2*DdXUD7w89iZt8A_Q5hA_RWZBLuBbLK?F;5Ghz=hoFXGI6S9Zu4A1fcxWJi1qTcU
> zk-!kw7$6kX!BYZH7CbxQSr1S8Yk^=Pyd$EzkNH5<56?F56Fmspv6ul}
> z#X>o}VPFEkNx%Sr`$3*sV;qLSGZE^Jh!Ct?1dM{GWQFNT+6Tw^o?jU$<0e=+K
> zjexWxq$BWC^L3Wv0b($GG8ACOq6eCcf3UcOX5smkGtokP#L~;ZdOjk=B7wI+un2G+
> zV}TK$MF^Hcx!S;q3y zpc5X8vG9x*3jE-i1 zfL6D|7=b&4MRm~;g2RA68G4MEDHOCqxr+)$0O>X4NkxLXok%blo`Ro{zz?2u>}utO
> zDsYIES9G!t2}+`2wqjtUF%g2>&{l;lFc?NuvQj9pT?Z0>)#39@cyG5ky(H+12!XlF
> z-iX#UFw2mh{5en;^?v0>A3L1Ar2vRa51b@ByYL4yN2*E;JXf?#M5$3e9~d#
> zIeG&<2n1q5<|QIZ9}M@f9p{T$Z7G`tWgb2Z*rKXvFSO>Jn3k8Rl0pI@u?F0B3
> z97Q>Fy#mmMfLQ_hcmmR`@Qwr>71#&_W_NHRmDIhxd-U;-vBy6q6n#uB`p6Z1Tq z;t_r1W9*TS2}dFKv$@UmrTM+BeGxi>r`kL~KjDF0f~3zq)bebdJeMDlAKPU z+aPp1!k%`XfII}!PI#7GA9NZg+XcE#_AHej(8=>^|9GPge08&`hHJlBbVo@4
> zg)i6*L^?FGsg=ANws9de1yzu~3tV58JOssrlU;zCma`-siXl#bVmYA1U%DIeCka
> zKVIYVK)%RYa>)=Wnf%DX)?1+FR_gxvmWi>ZN zS(l$MsJRuo%ys-ke8}zPfZ^8RRR>XY_FENOMz*l&-TOeyDX;uug6}I48UYszOJr
> zHKF*5`+iS_v1ubHhgMkYTieR7cQj51;oTlfQ9L!G|zsXuf2v!WjW@QM6=$j
> 

Re: [PATCH] linux-firmware: update firmware for Intel Broadwell SST DSP

[Kyle McMartin]

On Thu, Feb 05, 2015 at 11:27:04PM +0800, Jie Yang wrote:
 Update firmware intel/IntcSST2.bin from Version 8.4.1.68 to 8.4.1.77
 Fix for freeing capture stream just after resetting it.
 
 Signed-off-by: Jie Yang yang@intel.com

applied, thanks Jie.

regards, Kyle

 ---
  WHENCE |   1 +
  intel/IntcSST2.bin | Bin 260256 - 260320 bytes
  2 files changed, 1 insertion(+)
 
 diff --git a/WHENCE b/WHENCE
 index 7f2d6bf..6cb0778 100644
 --- a/WHENCE
 +++ b/WHENCE
 @@ -2646,6 +2646,7 @@ Licence: Redistributable. See LICENCE.it913x for details
  Driver: snd_soc_sst_acpi
  
  File: intel/IntcSST2.bin
 +Version: 8.4.1.77
  
  License: Redistributable. See LICENCE.IntcSST2 for details
  
 diff --git a/intel/IntcSST2.bin b/intel/IntcSST2.bin
 index 
 69ac37e78582dc5971b56eb598f43821958a9a59..e11cb61f4a00bf32a304781e3e9b1f32775285e1
  100644
 GIT binary patch
 delta 35726
 zcmZTQ30zZ0^VuW2oK~8w?O16AS%HV#UrQ)-guu?g3ntk+QXZpEkiRuwVPY+R95C
 z1q3z014NXdASf!}g=a;5UU+~gf};7)CeW|_{``KAwvv~%RnU?Cic|Hgnz)WzC
 zeOi^ts;SiKp^;p6Ocoyw;0_^rH9*B-$H^}w~@f{4iX$*9w7+5tNm(@$Zq{cp-i~
 zu;DM%P9V64qXs!wu$)?u?(R@*wd`f{Px^PfyI;vfjBQxFbm%6;XyBj0t)i!khX)
 zE4(S_)naOdz!CB;@LsbrLJ$Gz$9-#5%7$Mv(9Ziv)trP__v2$vE4rXGk5S46h6Z
 z!}kWmJxFIl=}veaLRuh*k8385EPJ_`Jfo4P69+c7s6h1Y1i6+C3+=4T8qQP-FeH
 z2*DdXUD7w89iZt8A_Q5hA_RWZBLuBbLK?F;5Ghz=hoFXGI6S9Zu4A1fcxWJi1qTcU
 zk-!kw7$6kX!BYZH7CbxQSr1S8Yk^=PydTVg2x3O0X$EzkNH556?F56Fmspv6ul}
 z#Xo}VPFEkNx%Sr`$3*sV;qLSGZE^Jh!Ct?1dM{GWQFNTWaG+6Tw^o?jU$0e=+K
 zjexWxq$BWC^L3Wv0b($GG8ACOq6eCcf3UcOX5smkGtokP#L~;ZdOjk=B7wI+un2G+
 zV}TK$MF^Hcxq!S;q3yS%W`XPK{a*xkau5K?=P67DE3KFviFTfj2zKA4|8LP5nS
 zpc5X8vG9x*3jE-i1z8zw|GVdhmd!0C@BSb5iH%Ow!sk;2b=MzDI)0sgQ=}5adV9
 zfL6D|7=b4MRm~;g2RA68G4MEDHOCqxr+)$0OX4NkxLXok%blo`Ro{zz?2u}utO
 zDsYIES9G!t2}+`2wqjtUF%g2{l;lFc?NuvQj9pT?Z0)#39@cyG5ky(H+12!XlF
 z-iX#UFw2mh{5en;^?v0NLQA3L1Ar2vRa51b@ByYL4yN2*E;JXf?#M5$3e9R~d#
 zIeG2n1q5|QIZ9}M@f9psVJ{T$Z7G`tWgb2Z*rKXvFSOJn3k8Rl0pI@u?F0B3
 z97QFy#mmMfLQ_hcmmR`@Qwr71#_W_NHRmDIhxd-U;-vBy6q6n#uB`p6Z1Tq!|
 z;t_r1W9*TS2}dFKv$@UmrTM+BeGxir`kL~KjDF0f~3zq)bebdJeMDlAKPULS6AC
 z+aPp1CUZo!k%`XfII}!PI#7GA9NZg+XcE#_AHej(8=^|9GPge08`hHJlBbVo@4
 zg)i6*Lq^?FGsg=ANws9de1yzu~3tV58JOssrlU;zCma`-siXl#bVmYA1U%DIeCka
 zKVIYVK)%RYa)=Wnf%DX)?1+FR_gxvmWiZNABm8M#K4|D~%pa-VEX*?TscFs^GR
 zS(l$MsJRuo%ys-ke8}zPfZ^8RRRYXY_FENOMz*l-TOeyDX;uug6}I48UYszOJr
 zHKF*5`+iS_v1ubHhgMkYTieR7cQj51;oTlfQ9LDoQQn!G|zsXuf2v!WjW@QM6=$j
 z!fY8@W_NVFg*sEFK!AItnu`hH+bcVMjU#`#CSipBg|uVA@jo``wwwRoM7rY-
 zCJ;AzIw4mq=^E%Hv-WKCSgybM0cb(OU5aGOxH#f*Fq(w8AqxP)4ZkXt=f`ycV^#E
 z1wQrWZ4!;4O;MNLsvI2%~XZ5RY7$v=v*(F6od7w}EeIzd_!gVYZ-jez3ZvJx
 z3?{HNnR(MennM813U`gWARaM$9~CPrr|x*Jg0#D@HapyNO;tmC)_4XtQeK3a^Twy
 zYPlQDdFKgJ@3dwJnN0l2+q2*A-l-%=h+DO#Uk!Xm4yQFH5TV-b}=OgTpvcX)%
 zy3+BQ@{S%Z^AGVP9~t@?FZR*;)=^ZjXJfF+O|5cKt6X(ljmL8Ox)CTKvpmm=zJ`a$
 zzn!*#R;!%zgiN*phLPg6`ne|EWFhKJmu!{=c%N-e@hnuMf2x?j!takky*X4$6SG
 z1ZaXDf*rc8M0yGZHnUws-{P)BtXy^)$MJ%|-Z8x9+GATl-cc6~621XPZri)K7+
 z1x{_(Wxipuu#66tb@MD1O^~jaZ;0N2=1JGeMQfuGKOKKYk3f6y9$JQe$4BWw-n%H$
 zZ04WLE-EXPvZ~qr?(4|lgy2htbWL+W1H^%fhVK74@7Brb9Z;N6Q_6YhJM5+y2o24
 zQN#4X1Zn|9^Iom`UbD;G0^!#};XxP}Am7EXs~uDqj}842?gxGcaE-v^)UF)V1K
 zv7hYJlOf?9{4aWB0#l)|L_diTUy9c_7ZVizMkll~e9`VI12*D*?dtqIN0QZDHn
 zVk}PZ8-iBjV!uHi%b~dDP7CE4ZYf9$u+L7FwRNH`#diKaXff{V|Fz`;GBB$vBmlR
 zzGxn^Ph;W;~oKH=mZ6fHR81-vmY@%To77aEJ(0#eaKyrZWlx{tGa`klse9x(9
 zAodFMMg8%pKyTC+GlBjn2%oqhf7_@V_U18d%u7TEyFA8gJQyju`pN*)!@Xp
 zQb{X_uo(Y9I`f1HS#P%qnajAk*9s)Vp}i;ev!lY~@)`A^2ix~i?OAqsAN-Ac-?*
 zB5Jv}_8a*T%NpxG6Q3fMIcNvKH2*$dW)0#9Guf)Rb%rud|!tKYTjDaNZ*znX(Tx
 zZ+MEHIlcKO@VLH;SL8*{TM;GMmKlWIFa^lPh{_BR9+PHY{h_(Q%C{}d!cukhX=
 z8g0WL0;aKz7lYCxW{jpKfESLHD0KqViV;?!g;I?bS=F5o0Sw5A!`vv_2VLlj-n
 zE8)I65YXN3Z?9ZmE?_qNIeih-9oeC8SNs_Xu8t;`CPBpf^d`or5W{;`+TwDl-Tw
 zqdLZN(uxauQ$SZlg*la;)|`go^L2u$u(HFjaUtu6INVz0F|HWAVE`P#mV0kC@U0_
 z$_@~7+=}xAPTFB?u|1Ncne$g8)$RHDopM(KZWdbL02(hwcogOC^A)^BWg253!j
 z)0~w=iX`_8TthRn2e@}xx`-tdU#HkS;*wzwtfK?3xRehD8)Vd`=Ysca{sT;FnqRu
 z@6cUVV1bg_3}jv5{%B^V5dIyOM4E?RH+VdoH-tIG7vmaT?Yt{EC6w)l5%@ei$8A
 z44CVfY8C$C?-3__(F`ao}W43oiK2eFL(ZRmYa7@JRRx#4^i_edri56kqY(YPIr_m
 z@#CgG!xT=YZJ94;~0AP%zjlde*@?l)=5U}lLV-LAkVLy~8i^cE(11P1D;tp_
 z4I@cM84}4O0|jAG(g9R_y{XXWwg0qlZ%B3t6pytY6ih#@1C+;^RX*snWl2*Cce%V
 zdaJ!P?Op#dG!uR_!S4_F7Vg^7uT!2e@AE$!;)bR-bS2znCP@6nNhe_x!q@b(u7t1j
 zcu9!Zw8W~z_!$k%}tWCh8uq`N}AqQ70NnA{mUlGzF@%X?slEx{gCd3FNDtV=wX%A
 zXb2svE%B^t*Az+_fh9FJo`C5|128JKZ++!wiFd%HI*p%xYSWw+!uVQD;IMjPr-a
 zdOBN4o*1}{CjOEM8f+8g0AJAuyU9OvcjJYn})s`NMjlxWh)UiLRuhUUFAX}?J#
 zM}oz=iVgwdkJloaxP8b=M9yy9kTyU$~iO@bgPJ!oak6P8#FCaZY^3|5ArGXxUW
 zDFN*4l=C-IPSR8mT@jTeE$xIg7FcTOrCF{I~VAYqAvAgc6JL^$%2Ws84xXyowk+z
 z$2Lz4?$mX6*;pG$pg^!l^Z1?o(KQH9p;U=}t7)jk)1IUs^00e~#acUyZmEcSmY;
 znT(p4SxeuRW;sf({;iqxEh!-;^Sb6H6eL{-I#lku%(bConHy5F_?qfn(A1H7p!lZz
 z1I=}5u*#iCoQW5jYfxT(=I?ejSEZot`)Tm3AjQ4HJu0#HJ7E~mpjPkYo+C94M1o@
 zdLyV$kX5#Qh)fkpTggV6%8qqhTnl|CZhn$ddd!NY-5`UfDh4okPK=Csr#!X`65
 zo3!!K0IT16yk%s7@58S2t**tQJ5rDFBmVSe7I;vvJ(MWyQoc?08h1CRxG4{$LB}-
 zP(@P7GXu1k*}@#hts^I(12}w?Z(Mh5H9-;^GQwu(%oiSCzU)faNVI@~%evQ)L!u
 

Re: Linux 3.19-rc3

[Kyle McMartin]

On Sat, Jan 10, 2015 at 04:29:39AM +0100, Laszlo Ersek wrote:
> I've bisected this issue to
> 

Awesome, this was on my list of list of suspicious commits to check
before my ARM64 box decided not to come back from reboot on Friday. :)

Thanks for bisecting!

cheers,
--Kyle

> > f045bbb9fa1bf6f507ad4de12d4e3471d8f672f1 is the first bad commit
> > commit f045bbb9fa1bf6f507ad4de12d4e3471d8f672f1
> > Author: Linus Torvalds 
> > Date:   Wed Dec 17 11:59:04 2014 -0800
> >
> > mmu_gather: fix over-eager tlb_flush_mmu_free() calling
> >
> > Dave Hansen reports that commit fb7332a9fedf ("mmu_gather: move minimal
> > range calculations into generic code") caused a performance problem:
> >
> >   "tlb_finish_mmu() goes up about 9x in the profiles (~0.4%->3.6%) and
> >tlb_flush_mmu_free() takes about 3.1% of CPU time with the patch
> >applied, but does not show up at all on the commit before"
> >
> > and the reason is that Will moved the test for whether we need to flush
> > from tlb_flush_mmu() into tlb_flush_mmu_tlbonly().  But that meant that
> > tlb_flush_mmu_free() basically lost that check.
> >
> > Move it back into tlb_flush_mmu() where it belongs, so that it covers
> > both tlb_flush_mmu_tlbonly() _and_ tlb_flush_mmu_free().
> >
> > Reported-and-tested-by: Dave Hansen 
> > Acked-by: Will Deacon 
> > Signed-off-by: Linus Torvalds 
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.19-rc3

[Kyle McMartin]

On Sat, Jan 10, 2015 at 04:29:39AM +0100, Laszlo Ersek wrote:
 I've bisected this issue to
 

Awesome, this was on my list of list of suspicious commits to check
before my ARM64 box decided not to come back from reboot on Friday. :)

Thanks for bisecting!

cheers,
--Kyle

  f045bbb9fa1bf6f507ad4de12d4e3471d8f672f1 is the first bad commit
  commit f045bbb9fa1bf6f507ad4de12d4e3471d8f672f1
  Author: Linus Torvalds torva...@linux-foundation.org
  Date:   Wed Dec 17 11:59:04 2014 -0800
 
  mmu_gather: fix over-eager tlb_flush_mmu_free() calling
 
  Dave Hansen reports that commit fb7332a9fedf (mmu_gather: move minimal
  range calculations into generic code) caused a performance problem:
 
tlb_finish_mmu() goes up about 9x in the profiles (~0.4%-3.6%) and
 tlb_flush_mmu_free() takes about 3.1% of CPU time with the patch
 applied, but does not show up at all on the commit before
 
  and the reason is that Will moved the test for whether we need to flush
  from tlb_flush_mmu() into tlb_flush_mmu_tlbonly().  But that meant that
  tlb_flush_mmu_free() basically lost that check.
 
  Move it back into tlb_flush_mmu() where it belongs, so that it covers
  both tlb_flush_mmu_tlbonly() _and_ tlb_flush_mmu_free().
 
  Reported-and-tested-by: Dave Hansen d...@sr71.net
  Acked-by: Will Deacon will.dea...@arm.com
  Signed-off-by: Linus Torvalds torva...@linux-foundation.org
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] radeon: add updated firmware for kaveri (radeon GPU)

[Kyle McMartin]

On Mon, Dec 22, 2014 at 01:26:44PM +0200, Oded Gabbay wrote:
> This firmware update is required for the correct functionality of AMD's HSA
> Linux kernel driver, called amdkfd.
> 
> amdkfd is a new driver that was merged by Linus last week and is present in
> 3.19-rc1.
> 
> Signed-off-by: Oded Gabbay 

pulled, thanks very much Oded.

regards, Kyle

> ---
>  radeon/kaveri_ce.bin   | Bin 8832 -> 8832 bytes
>  radeon/kaveri_me.bin   | Bin 8832 -> 8832 bytes
>  radeon/kaveri_mec.bin  | Bin 17024 -> 17024 bytes
>  radeon/kaveri_mec2.bin | Bin 17024 -> 17024 bytes
>  radeon/kaveri_pfp.bin  | Bin 8832 -> 8832 bytes
>  radeon/kaveri_rlc.bin  | Bin 10496 -> 10496 bytes
>  radeon/kaveri_sdma.bin | Bin 4456 -> 4456 bytes
>  7 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/radeon/kaveri_ce.bin b/radeon/kaveri_ce.bin
> index 
> d86d86e1cd712539fb1940cb58d91281e8554eea..95163d49ae6d4b75bd39da37f740dc5a508ce9cd
>  100644
> GIT binary patch
> delta 769
> zc${^SO-NKx6vzMPy*Klk5%UAb=ILVQnUaKoUlcM?Z>#}btS`cj_8lhUuj8~E}
> ziWXfzFs(pZ2oV`W(AQ$3oTUR
> z9ROlXXozwY_OHaJ?!l+lZTl7#ZboXj2>Ysalr==UR@b*lot_)bh(Cd8;4
> zb!iQ$5kFF+grJv1YfPc?gj)AEnz0P77jwM;J=rd9 z9F(SfK(+u*w!NO_56T1DhQg_wGwMNE+6{mDnjFwV;RI@31a9cG#yr3XA9`kv_pjw5
> z{^(-tFY%&0;e#^|^ezhdL)%0rWR2cN)AFbu>b%QtH6GA7YvN1wL!2@_2=sIM>}!
> zVKU5f<|VVhykb zX#cD=(}gG4w+sc@{6A3{y`8GldqA-@jdO=ktJ#_?N=D{ z#vs11{ITYLF04$h7?s-hRax$8r*_%vI%#zfF7(4$%+_d%Z86 zzq)tPaoJ*q!s_{yRh4hj5kqyj$GNpUU>^O0$IPs}WA353B&}QUU$Tw18)RULiqVJ?
> z9D;=qn$Sf8y)=NsbQ*owhH-4iG8_bGH;)zu~?=zMao-9WO(Hhuy}
> CmEV2<
> 
> delta 813
> zc${sKTSydP6vzL^ncZo zyrgEB)Jw3X2wg;I9@?ddRTCffp@bd+pL!~&7pL>#Kt?_M=KRl@^PQRh`K(r})vzjo
> zY5>G&$U;9y%h)Nr+}=D=wqQJ`ya4Rc0(1lwl+^Z$^;IY2~rO`$_@Ox36B2;;Q
> z(!5`VJ(dT1JO|yGb{^$}p5d^P4}H}ObLs@=g_uoi&_8M%mkE}{M6q28WO86;+K*BC
> zJRizM@GYS`yBxVZ-yS6^97#ClxDO@Xlo#cxry`LR3J;*lLuiVS*%a{sV|? zgg?3v=ZdmX7Au9B1}<$3i^Iwx8Wf#M8_kGGCDfVVZfOpvOKSKYT) znptMvFiGYe^Fg{~3aq{H4#%2UW1Y|XwAA8&8mMV;tm!qkBkXF~(ctQO2NNL&(`07F
> zW zBi#1@Pm(%%{=H?3di4`z>u}i%0)iqmPld1o&4}cZd$XOXeO z$6;=)Z)574GLUlES2mAqUfkzZh@!~bec38s$O+Mq=ZswU6|KSz0
> zB)({;RQY#{wR={}N6eaghT1kuDki89btu9G_z}W!w2_4_8pK5!LLW}zF6yxk6D8Dw
> d9=e8Jx`|s9#R$bvMwN)s@ZuSxmPEIq{st=3=F$KF
> 
> diff --git a/radeon/kaveri_me.bin b/radeon/kaveri_me.bin
> index 
> f65c1c86c417b3ed53c235c5e8fbe00756fd931e..4920e2ed5619e51c687d96c24416f0d465d6b327
>  100644
> GIT binary patch
> delta 1147
> zc$~G8O-K}B9LE3u*_n6Sa@(E#aCdgI-Em!0(zc~oofdP~kh17QMd;(8hrkT1q+_m)
> zg+?f8y;!Ia5?z8h6ibKZWFJrmDWrl9MTh9%p-zGkfxYi2waEruIy~>gJkS4~cjh;v
> zH|x!+UJg(L0LWwq0rJdsbtSm7OMI?8Q0oNQZHH0ZmYoxrY)rm zd2}=ia<`b7hD^OE0nF{+KKN=W-@4%haq=4gT>b#jjyFO2NRItZW_hwun9T4*@f0LA
> zJZbS9MmL@GgwaPIdR{xMc4iN2u6rACFP-;pspU@+h4-x?xSi{eKu zPUF4^cF<;D9b0q0SgIE?6A1BVQ8?Kag319tSyE{v{V+TAqufY(nZr6GDKoEP?qWV3
> zqc45CaUWIvUbOMG+QzmKyP<*oeuIsT2mrTuHWV{7Jywv>WRUOa^LzcgKj$~J)BeJK
> zFu2mlDMNFm3Y*8P=hP<+EtUN99B>=ja-?v2-a1DvO~;Q(RTApiew@wrvoAf|$>uLG
> zU17S(beHK2?JMoXYjnOeftM%-(s-UW1QOUydjpZp{{W-Qf?--P%px$%A}~w~hRI=A
> zd)B^~Sp<-20WymKGC3ftSqsDDFeKh|(uLqw^isdF1HaN1Wg464XQdkt(SxBh_Ry=L
> z12{t8hQ`XK*k831GVc(w{b{ICRPZSd$V?)*<6U$x9KhprGTe?&=$G(EZHY~PC#OV?
> zm)QB+|6O(_C(}kI7nRB)4!+w`zP9YC?S?AiH!7)T9m`S{!lVf*Xig2w>!yVjFA{
> v+o6ISg#mg`O 
> delta 1134
> zc$~G8Pe>F|9LImZ*`2peuI%wx(pROQ9~y>Ta
> zN}yreD?^2_Zo(YOrGYLX*r9_EQA9x@9Xfc^tRO1ry-8|?MY?qOzAy9r{@$CJ
> zGm2UZ& z>JS_!%&93zwV6eLh0f;7%A=%;9{_OWJ%kRva?{6-@ZV*4t_Nz%xZ
> zz0Un;r4!B|+UXc9+r;o7>LKS>DQWdm?GpA$iiLg*QH- z?i$R|jJuVsd3U(!ETnEDM4pDArz-$;gM89jr^Q?_H~FJhi#eD>g%-0hudkr5-R-!C
> zuJ~MteDxq3Cl)OZmIp}_8xa8RAkBJspZ2>Nc;6h;;?Y=1&$0_1Eq=yRy62w9mE?`1
> zMT^^7)=ys#Yw^+W`mBwe+ERKdT`}(Z!OvIOn}{3|>qS)412~r+U|)E+o9*gn8e+P|
> zbf4)Q?e`wX8}zL=idU)ROJE<(_@dZL`+POt4ImsdAm|1Jy$l51fS_{-NxcjNz051<
> zWx(hhOoLtqj9vzeZa~mE1d;dM^qYSh+Gs@HfuHCRc?#R<7x@%+((XV4Ptu9NJ{+ST
> z17p?W>@V60sW%Aefdn+l3b z$;2cvZDOjVp6VKj?>1CSR?nLXDf>;ujGw8foR_|fY4DL<5Tbb{=pf_(5OWu7Hs>Hj
> s4#Pz{qeL%VBY7AlgHRwtFiwVHk^FnuENsECKiB_34gWm+3!Zf_E=k
> 
> diff --git a/radeon/kaveri_mec.bin b/radeon/kaveri_mec.bin
> index 
> 96bc1c9f77e19b318d412c6af047bf8eb583dd5f..96322d60199a472d61c9b9b209ebb8e9b4a7c8dd
>  100644
> GIT binary patch
> delta 8620
> zc$}?SeRP!NmA~+r)Lng^&5;Bu8lbL)Fh9N-sFnNQ*7V8R92o?g0MYQ%~>xv)S
> zP3C>6)v_*C^vMTFC`T!J&`o>TwRSm{?Y{I(+1O4Jq|`=@E?U`QrIlS>5eUrw?mIJl
> zr0t&5bNa`f=led-bMJlb{oQx8M zl0Nd8W!fB{PBd6S%7B-+?u^$a-DEctxy%t7@_R`i&}e_%o$+m>Gfgz!
> z2-*pH5)=o`0o?_<8+1P?O>Xm66OD*lrI13_$$Bst^D52J1T`hMxs<*w@oi|
> zj18-jBsbSIkk)tdVzBbgxHMXVgB9aoqFY*dtAl8qY#p^=ghkQh2A9^m1*gm>t=CQa
> zOPtEX3DTW9QGrgj?a?Tuq9)QtB~tqAq>TScrX7VQ+F=JDNmDv2X@_@>OYat^r09Y#
> zQOeAdi1crM6~ej~v=u~(OMfYLIQ1av8W`v5WY5;ca(TY=O|eamNWJ2DIiRk`Xvj?3
> zMhj^_$Ro``!K6e%r-x|tITvY?u5><2v|~EClXGyCIB1)R`gvWNj)u{EGiy7r$a
> zYGL`H`_UKibF)O+8qiwMCQt}>`>f2T0#9n|s>SK+ND-ekRRufZ`N@+MDr=?vVVPpO
> znd()EVtKkLG$v6hB))7~Y$+$L|1R-8Q>io|erk%;@b#OZK>G?g>i6Yzz!MC
> zr^#|36j&~aOQzpSaq+%6V78LJOV};b19W|-1UivNJ8E$oSl)PmPM5? z%V(r##XnnCm^$KNk+zhXCE8pgeAWtSkC z?Qw3q(I$E$#X>!srh)H57zx@s!$kYzIAcGr1sx|EKDNaz
> zX=rI?kKcnDM;)XMR8ht7-O?`cbE~HS 

Re: [PATCH] radeon: add updated firmware for kaveri (radeon GPU)

[Kyle McMartin]

On Mon, Dec 22, 2014 at 01:26:44PM +0200, Oded Gabbay wrote:
 This firmware update is required for the correct functionality of AMD's HSA
 Linux kernel driver, called amdkfd.
 
 amdkfd is a new driver that was merged by Linus last week and is present in
 3.19-rc1.
 
 Signed-off-by: Oded Gabbay oded.gab...@amd.com

pulled, thanks very much Oded.

regards, Kyle

 ---
  radeon/kaveri_ce.bin   | Bin 8832 - 8832 bytes
  radeon/kaveri_me.bin   | Bin 8832 - 8832 bytes
  radeon/kaveri_mec.bin  | Bin 17024 - 17024 bytes
  radeon/kaveri_mec2.bin | Bin 17024 - 17024 bytes
  radeon/kaveri_pfp.bin  | Bin 8832 - 8832 bytes
  radeon/kaveri_rlc.bin  | Bin 10496 - 10496 bytes
  radeon/kaveri_sdma.bin | Bin 4456 - 4456 bytes
  7 files changed, 0 insertions(+), 0 deletions(-)
 
 diff --git a/radeon/kaveri_ce.bin b/radeon/kaveri_ce.bin
 index 
 d86d86e1cd712539fb1940cb58d91281e8554eea..95163d49ae6d4b75bd39da37f740dc5a508ce9cd
  100644
 GIT binary patch
 delta 769
 zc${^SO-NKx6vzMPy*Klk5%UAb=ILVQnUaKoUlcM?ZKuu#}btS`cj_8lhUuj8~E}
 ziWXfzFs(pZ2oV`W(AQ$3oTbJl$bF0wTV6gPhK#i41D-d*^@8`QLlqxmQF)#1UR
 z9ROlXXozwY_OHaJ?!l+lZTl7#ZboXj2Ysalr==G6lMuFUR@b*lot_)bh(Cd8;4
 zb!iQ$5kFF+grJv1YfPc?gj)AEnz0P77jwM;J=rd9v}pZ;YBlMEFG9o9$BaPtqegZ
 z9F(SfK(+u*w!NO_56T1DhQg_wGwMNE+6{mDnjFwV;RI@31a9cG#yr3XA9`kv_pjw5
 z{^(-tFY%0;e#^|^ezhdL)%0rWR2cN)AFbub%QtH6GA7YvN1wL!2@_2=sIM}o!
 zVKU5f|VVhykbXNL2Pma$;W^?KH=O3M{Ju%#s@CYJJ!t$D2+O?lmr!rR|6Xa-#
 zXEs#cD=(}gG4w+sc@{6A3{y`8GldqA-@jdO=ktJ#_?N=D{ppI50JavYz5b9)}
 z#vs11{ITYLF04$h7?s-hRax$8r*_%vI%#zfF7(4$%g+_d%Z86A3$?-j3u)mrgV!
 zzq)tPaoJ*q!s_{yRh4hj5kqyj$GNpUU^O0$IPs}WA353B}QUU$Tw18)RULiqVJ?
 z9D;=qn$Sf8y)=NsbQ*owhH-4iG8_bGH;ODqBMkIier)zuD~?=zMao-9WO(Hhuy}
 CmEV2
 
 delta 813
 zc${sKTSydP6vzL^ncZoD=MxLJ7ZfJXr%=`tmv#41S8T23wkjy^i_PQhrNs#U9bZC
 zyrgEB)Jw3X2wg;I9@?ddRTCffp@bd+pL!~7pL#Kt?_M=KRl@^PQRh`K(r})vzjo
 zY5G$U;9y%h)Nr+}=D=wqQJ`ya4Rc0(1lwl+^Z$lHF^;IY2~rO`$_@Ox36B2;;Q
 z(!5`VJ(dT1JO|yGb{^$}p5d^P4}H}ObLs@=g_uoi_8M%mkE}{M6q28WO86;+K*BC
 zJRizM@GYS`yBxVZ-yS6^97#ClxDO@Xlo#cxry`LR3J;*lLuiVS*%a{sV|?u%_Da+
 zgg?3v=ZdmX7Au9B1}$3i^Iwx8Wf#M8_kGGCDfVVZfOpvOKSKYT)V$hd`XmH*!Z
 znptMvFiGYe^Fg{~3aq{H4#%2UW1Y|XwAA88mMV;tm!qkBkXF~(ctQO2NNL(`07F
 zWZbKfZ}ARhlL{94Y1nNM~F4+u2t)*YT;d0uQ4;A(3os=%BC=903;@%JGl=Q$H
 zBi#1@Pm(%%Q{=H?3di4`zu}i%0)iqmPld1o4}cZd$XOXeOGn*oQQYxd@i!B0
 z$6;=)Z)574GLUlES2mAqUfkzZh@!KnkgbKYoV~bec38srzQ$O+Mq=ZswU6|KSz0
 zB)({;RQY#{wR={}N6eaghT1kuDki89btu9G_z}W!w2_4_8pK5!LLW}zF6yxk6D8Dw
 d9=e8Jx`|s9#R$bvMwN)s@ZuSxmPEIq{st=3=F$KF
 
 diff --git a/radeon/kaveri_me.bin b/radeon/kaveri_me.bin
 index 
 f65c1c86c417b3ed53c235c5e8fbe00756fd931e..4920e2ed5619e51c687d96c24416f0d465d6b327
  100644
 GIT binary patch
 delta 1147
 zc$~G8O-K}B9LE3u*_n6Sa@(E#aCdgI-Em!0(zc~oofdP~kh17QMd;(8hrkT1q+_m)
 zg+?f8y;!Ia5?z8h6ibKZWFJrmDWrl9MTh9%p-zGkfxYi2waEruIy~gJkS4~cjh;v
 zH|x!+UJg(L0LWwq0rJdsbtSm7OMI?8Q0oNQZHH0ZmYoxrY)rmk1#@iv;u%0d($*
 zd2}=ia`b7hD^OE0nF{+KKN=W-@4%haq=4gTb#jjyFO2NRItZW_hwun9T4*@f0LA
 zJZbS9MmL@GgwaPIdR{xMc4iN2u6rACFP-;pspU@+h4-x?xSi{eKuvQ1^2+J2UlI;
 zPUF4^cF;D9b0q0SgIE?6A1BVQ8?Kag319tSyE{v{V+TAqufY(nZr6GDKoEP?qWV3
 zqc45CaUWIvUbOMG+QzmKyP*oeuIsT2mrTuHWV{7JywvWRUOa^LzcgKj$~J)BeJK
 zFu2mlDMNFm3Y*8P=hP+EtUN99B=ja-?v2-a1DvO~;Q(RTApiew@wrvoAf|$uLG
 zU17S(beHK2?JMoXYjnOeftM%-(s-UW1QOUydjpZp{{W-Qf?--P%px$%A}~w~hRI=A
 zd)B^~Sp-20WymKGC3ftSqsDDFeKh|(uLqw^isdF1HaN1Wg464XQdkt(SxBh_Ry=L
 z12{t8hQ`XK*k831GVc(w{b{ICRPZSd$V?)*6U$x9KhprGTe?=$G(EZHY~PC#OV?
 zm)QB+|6O(_C(}kI7nRB)4!+w`zP9YC?S?AiH!7)T9m`S{!lVf*Xig2wX!yVjFA{
 v+o6ISg#mg`OWu$IT$AcFhPc3iVVXiG6IXlWyy)HP=RB=uK$Co|9SW)xjHf~
 
 delta 1134
 zc$~G8PeF|9LImZ*`2peuIFmvzxf%wx(pROQ9~yTa?cBplUim(nDWd(KdV7N9
 zN}yreD?^2_Zo(YOrGYLX*r9_EQA9x@9Xfc^tRO1ry-8|?MY?qOzAy9r{@$CJy1Q;
 zGm2UZFs?WB~zYnXAh0U~*}`-uqB#6zLzjAB!IL0~d5*^9lx2q~opjrh`xi1${
 zJS_!%93zwV6eLh0f;7sU4t%A=%;9{_OWJ%kRva?{6-@ZVPCrhQtG*4t_Nz%xZ
 zz0Un;r4!B|+UXbOUY=bceAG8c9+r;o7LKSDQWdm?GpA$iiLg*QH-tc^T;@(A
 z?i$R|jJuVsd3U(!ETnEDM4pDArz-$;gM89jr^Q?_H~FJhi#eDg%-0hudkr5-R-!C
 zuJ~MteDxq3Cl)OZmIp}_8xa8RAkBJspZ2Nc;6h;;?Y=1$0_1Eq=yRy62w9mE?`1
 zMT^^7)=ys#Yw^+W`mBwe+ERKdT`}(Z!OvIOn}{3|qS)412~r+U|)E+o9*gn8e+P|
 zbf4)Q?e`wX8}zL=idU)ROJE(_@dZL`+POt4ImsdAm|1Jy$l51fS_{-NxcjNz051
 zWx(hhOoLtqj9vzeZa~mE1d;dM^qYSh+Gs@HfuHCRc?#R7x@%+((XV4Ptu9NJ{+ST
 z17p?W@V60sW%Aefdn+l3btnQWFUFNDnOpee8{Af;oIbe+C!ht8Dr!Ic?@x1q-Mf
 z$;2cvZDOjVp6VKj?1CSR?nLXDf;ujGw8foR_|fY4DL5Tbb{=pf_(5OWu7HsHj
 s4#Pz{qeL%VBY7AlgHRwtFiwVHkM7Hu^FnuENsECKiB_34gWm+3!Zf_Eu=k
 
 diff --git a/radeon/kaveri_mec.bin b/radeon/kaveri_mec.bin
 index 
 96bc1c9f77e19b318d412c6af047bf8eb583dd5f..96322d60199a472d61c9b9b209ebb8e9b4a7c8dd
  100644
 GIT binary patch
 delta 8620
 zc$}?SeRP!NmA~h-;+r)Lng^5;Bu8lbL)Fh9N-sFnNQ*7V8R92o?g0MYQ%~xv)S
 zP3C6)v_*C^vMTFC`T!J`oTwRSm{?Y{I(+1O4Jq|`=@E?U`QrIlS5eUrw?mIJl
 zr0t5bNa`f=led-bMJlb{oQx8MneLsY+Wy)IdZM$VM`K3l*`)3N`p*j(R}RVTN^
 zl0Nd8W!fB{PBd6S%7B-kpwMHKI78+?u^$a-DEctxy%t7@_R`i}e_%o$+mGfgz!
 z2-*pH5)=o`0o?_8+1P?OXm66OD*lrI13_$$Bst^D52J1T`hMxs*w@oiXQj86|
 zj18-jBsbSIkk)tdVzBbgxHMXVgB9aoqFY*dtAl8qY#p^=ghkQh2A9^m1*gmt=CQa
 

[PATCH] uapi/linux/target_core_user.h: fix headers_install.sh badness

[Kyle McMartin]

scripts/headers_install.sh will transform __packed to
__attribute__((packed)), so the #ifndef is not necessary.
(and, in fact, it's problematic, because we'll end up with the header
 containing:
#ifndef __attribute__((packed))
#define __attribu...
and so forth.)

Cc: sta...@vger.kernel.org # 3.18
Signed-off-by: Kyle McMartin 

---
cc-ing stable@ so this headers fix gets picked up by distros.

--- a/include/uapi/linux/target_core_user.h
+++ b/include/uapi/linux/target_core_user.h
@@ -6,10 +6,6 @@
 #include 
 #include 
 
-#ifndef __packed
-#define __packed__attribute__((packed))
-#endif
-
 #define TCMU_VERSION "1.0"
 
 /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] uapi/linux/target_core_user.h: fix headers_install.sh badness

[Kyle McMartin]

scripts/headers_install.sh will transform __packed to
__attribute__((packed)), so the #ifndef is not necessary.
(and, in fact, it's problematic, because we'll end up with the header
 containing:
#ifndef __attribute__((packed))
#define __attribu...
and so forth.)

Cc: sta...@vger.kernel.org # 3.18
Signed-off-by: Kyle McMartin k...@redhat.com

---
cc-ing stable@ so this headers fix gets picked up by distros.

--- a/include/uapi/linux/target_core_user.h
+++ b/include/uapi/linux/target_core_user.h
@@ -6,10 +6,6 @@
 #include linux/types.h
 #include linux/uio.h
 
-#ifndef __packed
-#define __packed__attribute__((packed))
-#endif
-
 #define TCMU_VERSION 1.0
 
 /*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 1/1] linux-firmware: Update AMD microcode patch firmware files

[Kyle McMartin]

On Thu, Nov 06, 2014 at 07:38:26PM -0600, sherry.hurw...@amd.com wrote:
> From: Sherry Hurwitz 
> 
> For AMD Family 15h Processors
> file:   amd-ucode/microcode_amd_family15h.bin
> md5sum: ee3f0f46936aa1788dc31ca3487e0ff3
> 
> For AMD Family 16h Processors
> file:   amd-ucode/microcode_amd_family16h.bin
> md5sum: 6a47a6393c52ddfc0b5b044efc076a77
> 
> Version: 2014_10_28
> Signed-off-by: Sherry Hurwitz 

Applied, thanks Sherry. Sorry for the delay.

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Do you know who maintains firmware upstreaming for linux now?

[Kyle McMartin]

On Fri, Nov 28, 2014 at 11:51:16AM +, Jie, Yang wrote:
> 
> Hi, All,
> 
> Could someone clarify who maintains firmware upstreaming to Linux at the 
> moment?
> 
> We are working on upstream a firmware binary and its license to 
> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, 
> We've sent the patch to linux-firmw...@kernel.org but got no reply for 
> several(4~5) weeks.
> I can imagine that maintainers may be very busy, and not sure if Ben/Kyle 
> have been on vacation, or can someone else help to review and apply our 
> firmware patch? 
> 

Sorry, we've just been busy, and I figured someone would pick up my
slacking... I'll get to it tonight.

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Do you know who maintains firmware upstreaming for linux now?

[Kyle McMartin]

On Fri, Nov 28, 2014 at 11:51:16AM +, Jie, Yang wrote:
 
 Hi, All,
 
 Could someone clarify who maintains firmware upstreaming to Linux at the 
 moment?
 
 We are working on upstream a firmware binary and its license to 
 git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, 
 We've sent the patch to linux-firmw...@kernel.org but got no reply for 
 several(4~5) weeks.
 I can imagine that maintainers may be very busy, and not sure if Ben/Kyle 
 have been on vacation, or can someone else help to review and apply our 
 firmware patch? 
 

Sorry, we've just been busy, and I figured someone would pick up my
slacking... I'll get to it tonight.

regards, Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [RESEND PATCH 1/1] linux-firmware: Update AMD microcode patch firmware files

[Kyle McMartin]

On Thu, Nov 06, 2014 at 07:38:26PM -0600, sherry.hurw...@amd.com wrote:
 From: Sherry Hurwitz sherry.hurw...@amd.com
 
 For AMD Family 15h Processors
 file:   amd-ucode/microcode_amd_family15h.bin
 md5sum: ee3f0f46936aa1788dc31ca3487e0ff3
 
 For AMD Family 16h Processors
 file:   amd-ucode/microcode_amd_family16h.bin
 md5sum: 6a47a6393c52ddfc0b5b044efc076a77
 
 Version: 2014_10_28
 Signed-off-by: Sherry Hurwitz sherry.hurw...@amd.com

Applied, thanks Sherry. Sorry for the delay.

regards, Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: __clear_user: handle exceptions on strb

[Kyle McMartin]

On Thu, Nov 13, 2014 at 03:06:25PM +, Catalin Marinas wrote:
> On Wed, Nov 12, 2014 at 09:07:44PM +0000, Kyle McMartin wrote:
> > ARM64 currently doesn't fix up faults on the single-byte (strb) case of
> > __clear_user... which means that we can cause a nasty kernel panic as an
> > ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
> > i.e.: dd if=/dev/zero of=foo ibs=1 count=1 (or ibs=65537, etc.)
> 
> Thanks for this, it's been like this for a while. Applied.
> 

Thanks Catalin, if it's not too late, I forgot to add a
Reported-by: Miloš Prchlík 
for the initial report of the panic.

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: __clear_user: handle exceptions on strb

[Kyle McMartin]

On Thu, Nov 13, 2014 at 03:06:25PM +, Catalin Marinas wrote:
 On Wed, Nov 12, 2014 at 09:07:44PM +, Kyle McMartin wrote:
  ARM64 currently doesn't fix up faults on the single-byte (strb) case of
  __clear_user... which means that we can cause a nasty kernel panic as an
  ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
  i.e.: dd if=/dev/zero of=foo ibs=1 count=1 (or ibs=65537, etc.)
 
 Thanks for this, it's been like this for a while. Applied.
 

Thanks Catalin, if it's not too late, I forgot to add a
Reported-by: Miloš Prchlík mprch...@redhat.com
for the initial report of the panic.

regards, Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: __clear_user: handle exceptions on strb

[Kyle McMartin]

ARM64 currently doesn't fix up faults on the single-byte (strb) case of
__clear_user... which means that we can cause a nasty kernel panic as an
ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
i.e.: dd if=/dev/zero of=foo ibs=1 count=1 (or ibs=65537, etc.)

This is a pretty obscure bug in the general case since we'll only
__do_kernel_fault (since there's no extable entry for pc) if the
mmap_sem is contended. However, with CONFIG_DEBUG_VM enabled, we'll
always fault.

if (!down_read_trylock(>mmap_sem)) {
if (!user_mode(regs) && !search_exception_tables(regs->pc))
goto no_context;
retry:
down_read(>mmap_sem);
} else {
/*
 * The above down_read_trylock() might have succeeded in
 * which
 * case, we'll have missed the might_sleep() from
 * down_read().
 */
might_sleep();
#ifdef CONFIG_DEBUG_VM
if (!user_mode(regs) && !search_exception_tables(regs->pc))
goto no_context;
#endif
}

Fix that by adding an extable entry for the strb instruction, since it
touches user memory, similar to the other stores in __clear_user.

Signed-off-by: Kyle McMartin 
Cc: sta...@vger.kernel.org

--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -46,7 +46,7 @@ USER(9f, strh wzr, [x0], #2   )
sub x1, x1, #2
 4: addsx1, x1, #1
b.mi5f
-   strbwzr, [x0]
+USER(9f, strb  wzr, [x0]   )
 5: mov x0, #0
ret
 ENDPROC(__clear_user)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: __clear_user: handle exceptions on strb

[Kyle McMartin]

ARM64 currently doesn't fix up faults on the single-byte (strb) case of
__clear_user... which means that we can cause a nasty kernel panic as an
ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
i.e.: dd if=/dev/zero of=foo ibs=1 count=1 (or ibs=65537, etc.)

This is a pretty obscure bug in the general case since we'll only
__do_kernel_fault (since there's no extable entry for pc) if the
mmap_sem is contended. However, with CONFIG_DEBUG_VM enabled, we'll
always fault.

if (!down_read_trylock(mm-mmap_sem)) {
if (!user_mode(regs)  !search_exception_tables(regs-pc))
goto no_context;
retry:
down_read(mm-mmap_sem);
} else {
/*
 * The above down_read_trylock() might have succeeded in
 * which
 * case, we'll have missed the might_sleep() from
 * down_read().
 */
might_sleep();
#ifdef CONFIG_DEBUG_VM
if (!user_mode(regs)  !search_exception_tables(regs-pc))
goto no_context;
#endif
}

Fix that by adding an extable entry for the strb instruction, since it
touches user memory, similar to the other stores in __clear_user.

Signed-off-by: Kyle McMartin k...@redhat.com
Cc: sta...@vger.kernel.org

--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -46,7 +46,7 @@ USER(9f, strh wzr, [x0], #2   )
sub x1, x1, #2
 4: addsx1, x1, #1
b.mi5f
-   strbwzr, [x0]
+USER(9f, strb  wzr, [x0]   )
 5: mov x0, #0
ret
 ENDPROC(__clear_user)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] lib/halfmd4: make build optional

[Kyle McMartin]

On Thu, Nov 06, 2014 at 04:27:33PM -0500, Aristeu Rozanski wrote:
> +config HALF_MD4
> + bool "Half MD4 transform"
> + default y
> + help
> +   This option enables a reduced (32 bit output) version of MD4
> +   transform.
> +

i'd suggest just def_bool n, and not have this prompt the user at all...
it only provides a single export_symbol, so a user doesn't really need
to care.

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/halfmd4: make build optional

[Kyle McMartin]

On Thu, Nov 06, 2014 at 04:27:33PM -0500, Aristeu Rozanski wrote:
 +config HALF_MD4
 + bool Half MD4 transform
 + default y
 + help
 +   This option enables a reduced (32 bit output) version of MD4
 +   transform.
 +

i'd suggest just def_bool n, and not have this prompt the user at all...
it only provides a single export_symbol, so a user doesn't really need
to care.

regards, Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] aarch64: filter $x from kallsyms

[Kyle McMartin]

Similar to ARM, AArch64 is generating $x and $d syms... which isn't
terribly helpful when looking at %pF output and the like. Filter those
out in kallsyms, modpost and when looking at module symbols.

Seems simplest since none of these check EM_ARM anyway, to just add it
to the strchr used, rather than trying to make things overly
complicated.

initcall_debug improves:
dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs
dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs

Signed-off-by: Kyle McMartin 

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3388,7 +3388,7 @@ static inline int is_arm_mapping_symbol(const char *str)
 {
if (str[0] == '.' && str[1] == 'L')
return true;
-   return str[0] == '$' && strchr("atd", str[1])
+   return str[0] == '$' && strchr("axtd", str[1])
   && (str[2] == '\0' || str[2] == '.');
 }
 
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -84,7 +84,7 @@ static void usage(void)
  */
 static inline int is_arm_mapping_symbol(const char *str)
 {
-   return str[0] == '$' && strchr("atd", str[1])
+   return str[0] == '$' && strchr("axtd", str[1])
   && (str[2] == '\0' || str[2] == '.');
 }
 
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1146,7 +1146,7 @@ static Elf_Sym *find_elf_symbol(struct elf_info *elf, 
Elf64_Sword addr,
 
 static inline int is_arm_mapping_symbol(const char *str)
 {
-   return str[0] == '$' && strchr("atd", str[1])
+   return str[0] == '$' && strchr("axtd", str[1])
   && (str[2] == '\0' || str[2] == '.');
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm/radeon: delete unused PTE_* defines

[Kyle McMartin]

They don't appear to be used anywhere... elsewhere uses R*_PTE_*.

master@linux:U:.% git grep PTE_ -- drivers/gpu/drm/radeon | grep -v _PTE_
master@linux:U:.%   (kyle@redacted:~/linux)

./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the 
previous definition
 #define PTE_VALID  (_AT(pteval_t, 1) << 0)
 ^
In file included from drivers/gpu/drm/radeon/r600_cs.c:31:0:
drivers/gpu/drm/radeon/r600d.h:48:0: warning: "PTE_VALID" redefined [enabled by 
default]
 #define PTE_VALID(1 << 0)
 ^
In file included from ./arch/arm64/include/asm/io.h:29:0,
 from include/linux/clocksource.h:19,
 from include/clocksource/arm_arch_timer.h:19,
 from ./arch/arm64/include/asm/arch_timer.h:27,
 from ./arch/arm64/include/asm/timex.h:19,
 from include/linux/timex.h:65,

 from include/drm/drmP.h:51,
 from drivers/gpu/drm/radeon/r600_cs.c:29:
./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the 
previous definition
 #define PTE_VALID  (_AT(pteval_t, 1) << 0)
 ^

Signed-off-by: Kyle McMartin 

--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -44,13 +44,6 @@
 #define R6XX_MAX_PIPES 8
 #define R6XX_MAX_PIPES_MASK0xff
 
-/* PTE flags */
-#define PTE_VALID  (1 << 0)
-#define PTE_SYSTEM (1 << 1)
-#define PTE_SNOOPED(1 << 2)
-#define PTE_READABLE   (1 << 5)
-#define PTE_WRITEABLE  (1 << 6)
-
 /* tiling bits */
 #define ARRAY_LINEAR_GENERAL  0x
 #define ARRAY_LINEAR_ALIGNED  0x0001
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/radeon: delete unused PTE_* defines

[Kyle McMartin]

They don't appear to be used anywhere... elsewhere uses R*_PTE_*.

master@linux:U:.% git grep PTE_ -- drivers/gpu/drm/radeon | grep -v _PTE_
master@linux:U:.%   (kyle@redacted:~/linux)

./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the 
previous definition
 #define PTE_VALID  (_AT(pteval_t, 1)  0)
 ^
In file included from drivers/gpu/drm/radeon/r600_cs.c:31:0:
drivers/gpu/drm/radeon/r600d.h:48:0: warning: PTE_VALID redefined [enabled by 
default]
 #define PTE_VALID(1  0)
 ^
In file included from ./arch/arm64/include/asm/io.h:29:0,
 from include/linux/clocksource.h:19,
 from include/clocksource/arm_arch_timer.h:19,
 from ./arch/arm64/include/asm/arch_timer.h:27,
 from ./arch/arm64/include/asm/timex.h:19,
 from include/linux/timex.h:65,
snip
 from include/drm/drmP.h:51,
 from drivers/gpu/drm/radeon/r600_cs.c:29:
./arch/arm64/include/asm/pgtable.h:27:0: note: this is the location of the 
previous definition
 #define PTE_VALID  (_AT(pteval_t, 1)  0)
 ^

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -44,13 +44,6 @@
 #define R6XX_MAX_PIPES 8
 #define R6XX_MAX_PIPES_MASK0xff
 
-/* PTE flags */
-#define PTE_VALID  (1  0)
-#define PTE_SYSTEM (1  1)
-#define PTE_SNOOPED(1  2)
-#define PTE_READABLE   (1  5)
-#define PTE_WRITEABLE  (1  6)
-
 /* tiling bits */
 #define ARRAY_LINEAR_GENERAL  0x
 #define ARRAY_LINEAR_ALIGNED  0x0001
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] aarch64: filter $x from kallsyms

[Kyle McMartin]

Similar to ARM, AArch64 is generating $x and $d syms... which isn't
terribly helpful when looking at %pF output and the like. Filter those
out in kallsyms, modpost and when looking at module symbols.

Seems simplest since none of these check EM_ARM anyway, to just add it
to the strchr used, rather than trying to make things overly
complicated.

initcall_debug improves:
dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs
dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3388,7 +3388,7 @@ static inline int is_arm_mapping_symbol(const char *str)
 {
if (str[0] == '.'  str[1] == 'L')
return true;
-   return str[0] == '$'  strchr(atd, str[1])
+   return str[0] == '$'  strchr(axtd, str[1])
(str[2] == '\0' || str[2] == '.');
 }
 
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -84,7 +84,7 @@ static void usage(void)
  */
 static inline int is_arm_mapping_symbol(const char *str)
 {
-   return str[0] == '$'  strchr(atd, str[1])
+   return str[0] == '$'  strchr(axtd, str[1])
(str[2] == '\0' || str[2] == '.');
 }
 
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1146,7 +1146,7 @@ static Elf_Sym *find_elf_symbol(struct elf_info *elf, 
Elf64_Sword addr,
 
 static inline int is_arm_mapping_symbol(const char *str)
 {
-   return str[0] == '$'  strchr(atd, str[1])
+   return str[0] == '$'  strchr(axtd, str[1])
(str[2] == '\0' || str[2] == '.');
 }
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf tools: Allow to specify lib compile variable for spec usage

[Kyle McMartin]

On Mon, Aug 25, 2014 at 10:55 AM, Jiri Olsa  wrote:
> We need a way to specify $(lib) part of the installation
> path for traceevent plugin libraries. Currently we use
> 'lib64' for x86_64 and 'lib' otherwise.
>
> Instead of listing all possible values, this change allows
> the rpm spec code to specify the correct $(lib) part based
> on processed architecture, like
>
>   $ make ... lib=%{_lib}
>
> Cc: Kyle McMartin 

I had made a similar change to Fedora, which I replaced with this, and
it worked fine.
LGTM :)

Tested-by: Kyle McMartin 

> Cc: Arnaldo Carvalho de Melo 
> Cc: Corey Ashford 
> Cc: David Ahern 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 
> Cc: Namhyung Kim 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/config/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
> index 75d4c237b03d..eaf36dafb482 100644
> --- a/tools/perf/config/Makefile
> +++ b/tools/perf/config/Makefile
> @@ -651,11 +651,13 @@ else
>  sysconfdir = $(prefix)/etc
>  ETC_PERFCONFIG = etc/perfconfig
>  endif
> +ifndef lib
>  ifeq ($(IS_X86_64),1)
>  lib = lib64
>  else
>  lib = lib
>  endif
> +endif # lib
>  libdir = $(prefix)/$(lib)
>
>  # Shell quote (do not use $(call) to accommodate ancient setups);
> --
> 1.8.3.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] perf tools: Allow to specify lib compile variable for spec usage

[Kyle McMartin]

On Mon, Aug 25, 2014 at 10:55 AM, Jiri Olsa jo...@kernel.org wrote:
 We need a way to specify $(lib) part of the installation
 path for traceevent plugin libraries. Currently we use
 'lib64' for x86_64 and 'lib' otherwise.

 Instead of listing all possible values, this change allows
 the rpm spec code to specify the correct $(lib) part based
 on processed architecture, like

   $ make ... lib=%{_lib}

 Cc: Kyle McMartin k...@mcmartin.ca

I had made a similar change to Fedora, which I replaced with this, and
it worked fine.
LGTM :)

Tested-by: Kyle McMartin k...@mcmartin.ca

 Cc: Arnaldo Carvalho de Melo a...@kernel.org
 Cc: Corey Ashford cjash...@linux.vnet.ibm.com
 Cc: David Ahern dsah...@gmail.com
 Cc: Frederic Weisbecker fweis...@gmail.com
 Cc: Ingo Molnar mi...@kernel.org
 Cc: Namhyung Kim namhy...@kernel.org
 Cc: Paul Mackerras pau...@samba.org
 Cc: Peter Zijlstra a.p.zijls...@chello.nl
 Signed-off-by: Jiri Olsa jo...@kernel.org
 ---
  tools/perf/config/Makefile | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
 index 75d4c237b03d..eaf36dafb482 100644
 --- a/tools/perf/config/Makefile
 +++ b/tools/perf/config/Makefile
 @@ -651,11 +651,13 @@ else
  sysconfdir = $(prefix)/etc
  ETC_PERFCONFIG = etc/perfconfig
  endif
 +ifndef lib
  ifeq ($(IS_X86_64),1)
  lib = lib64
  else
  lib = lib
  endif
 +endif # lib
  libdir = $(prefix)/$(lib)

  # Shell quote (do not use $(call) to accommodate ancient setups);
 --
 1.8.3.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: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Aug 06, 2014 at 12:06:29PM +0530, Hariprasad S wrote:
> On Mon, Aug 04, 2014 at 13:48:31 -0400, Kyle McMartin wrote:
> > On Fri, Jun 27, 2014 at 05:39:11PM +0530, Hariprasad S wrote:
> > > Hi,
> > > 
> > > Can you please pull from the following URL?
> > > git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> > > 
> > 
> > Trying to pull this for you right now... git.chelsio.net seems to be
> > offline though.
> > 
> > regards, Kyle
> > 
> 
> My bad. We had some issue with our git server due to power-surge.
> Can you please retry now?
> 
> Thanks, Hari
> 

Worked this time... I just cherry-picked it in to avoid the unnecessary
merge commit.

--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Wed, Aug 06, 2014 at 12:06:29PM +0530, Hariprasad S wrote:
 On Mon, Aug 04, 2014 at 13:48:31 -0400, Kyle McMartin wrote:
  On Fri, Jun 27, 2014 at 05:39:11PM +0530, Hariprasad S wrote:
   Hi,
   
   Can you please pull from the following URL?
   git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
   
  
  Trying to pull this for you right now... git.chelsio.net seems to be
  offline though.
  
  regards, Kyle
  
 
 My bad. We had some issue with our git server due to power-surge.
 Can you please retry now?
 
 Thanks, Hari
 

Worked this time... I just cherry-picked it in to avoid the unnecessary
merge commit.

--Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: Who maintains firmware upstreaming to Linux now?

[Kyle McMartin]

On Tue, Aug 05, 2014 at 06:59:38AM +, Lin, Mengdong wrote:
> Hi,
> 
> Could someone clarify who maintains firmware upstreaming to Linux at the 
> moment?
> 
> We need to upstream a firmware binary and its license. We've submitted the 
> patch to linux-firmw...@kernel.org but got no reply for 5 weeks.
> I'm not sure if Ben has been on vacation, or someone else can help to review 
> and apply our firmware patch.
> 

I'm sure we're all quite busy, but I'm working on the back log now.

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Who maintains firmware upstreaming to Linux now?

[Kyle McMartin]

On Tue, Aug 05, 2014 at 06:59:38AM +, Lin, Mengdong wrote:
 Hi,
 
 Could someone clarify who maintains firmware upstreaming to Linux at the 
 moment?
 
 We need to upstream a firmware binary and its license. We've submitted the 
 patch to linux-firmw...@kernel.org but got no reply for 5 weeks.
 I'm not sure if Ben has been on vacation, or someone else can help to review 
 and apply our firmware patch.
 

I'm sure we're all quite busy, but I'm working on the back log now.

regards, Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Fri, Jun 27, 2014 at 05:39:11PM +0530, Hariprasad S wrote:
> Hi,
> 
> Can you please pull from the following URL?
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 

Trying to pull this for you right now... git.chelsio.net seems to be
offline though.

regards, Kyle

> The following changes since commit 7f388b4885cf64d6b7833612052d20d4197af96f:
> Ben Hutchings (1):
> Move the s5p-mfc firmware out of its subdirectory
> 
> are available in the git repository at:
> 
> git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
> 
> Hariprasad Shenai (1):
> cxgb4: Update firmware to revision 1.11.27.0
> 
> LICENCE.chelsio_firmware |2 +-
> WHENCE   |8 
> cxgb4/t4fw-1.11.27.0.bin |  Bin 0 -> 512512 bytes
> cxgb4/t4fw-1.9.23.0.bin  |  Bin 486912 -> 0 bytes
> cxgb4/t4fw.bin   |2 +-
> cxgb4/t5fw-1.11.27.0.bin |  Bin 0 -> 513024 bytes
> cxgb4/t5fw-1.9.23.0.bin  |  Bin 481280 -> 0 bytes
> cxgb4/t5fw.bin   |2 +-
> 8 files changed, 7 insertions(+), 7 deletions(-)
> create mode 100644 cxgb4/t4fw-1.11.27.0.bin
> delete mode 100644 cxgb4/t4fw-1.9.23.0.bin
> create mode 100644 cxgb4/t5fw-1.11.27.0.bin
> delete mode 100644 cxgb4/t5fw-1.9.23.0.bin
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: linux-firmware: update cxgb4 firmware

[Kyle McMartin]

On Fri, Jun 27, 2014 at 05:39:11PM +0530, Hariprasad S wrote:
 Hi,
 
 Can you please pull from the following URL?
 git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
 

Trying to pull this for you right now... git.chelsio.net seems to be
offline though.

regards, Kyle

 The following changes since commit 7f388b4885cf64d6b7833612052d20d4197af96f:
 Ben Hutchings (1):
 Move the s5p-mfc firmware out of its subdirectory
 
 are available in the git repository at:
 
 git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
 
 Hariprasad Shenai (1):
 cxgb4: Update firmware to revision 1.11.27.0
 
 LICENCE.chelsio_firmware |2 +-
 WHENCE   |8 
 cxgb4/t4fw-1.11.27.0.bin |  Bin 0 - 512512 bytes
 cxgb4/t4fw-1.9.23.0.bin  |  Bin 486912 - 0 bytes
 cxgb4/t4fw.bin   |2 +-
 cxgb4/t5fw-1.11.27.0.bin |  Bin 0 - 513024 bytes
 cxgb4/t5fw-1.9.23.0.bin  |  Bin 481280 - 0 bytes
 cxgb4/t5fw.bin   |2 +-
 8 files changed, 7 insertions(+), 7 deletions(-)
 create mode 100644 cxgb4/t4fw-1.11.27.0.bin
 delete mode 100644 cxgb4/t4fw-1.9.23.0.bin
 create mode 100644 cxgb4/t5fw-1.11.27.0.bin
 delete mode 100644 cxgb4/t5fw-1.9.23.0.bin
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trivial] checkstack.pl: port to AArch64

[Kyle McMartin]

AArch64 stores the frame pointer and return pointer, and decrements the
stack. Also remove my (no longer valid) email address.

Signed-off-by: Kyle McMartin 

--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -13,7 +13,7 @@
 #  Random bits by Matt Mackall 
 #  M68k port by Geert Uytterhoeven and Andreas Schwab
 #  AVR32 port by Haavard Skinnemoen (Atmel)
-#  PARISC port by Kyle McMartin 
+#  AArch64, PARISC ports by Kyle McMartin
 #  sparc port by Martin Habets 
 #
 #  Usage:
@@ -45,7 +45,10 @@ my (@stack, $re, $dre, $x, $xs, $funcre);
$x  = "[0-9a-f]";   # hex character
$xs = "[0-9a-f ]";  # hex character or space
$funcre = qr/^$x* <(.*)>:$/;
-   if ($arch eq 'arm') {
+   if ($arch eq 'aarch64') {
+   #ffc0006325cc:   a9bb7bfdstp x29, x30, 
[sp,#-80]!
+   $re = qr/^.*stp.*sp,\#-([0-9]{1,8})\]\!/o;
+   } elsif ($arch eq 'arm') {
#c0008ffc:  e24dd064sub sp, sp, #100; 0x64
$re = qr/.*sub.*sp, sp, #(([0-9]{2}|[3-9])[0-9]{2})/o;
} elsif ($arch eq 'avr32') {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trivial] checkstack.pl: port to AArch64

[Kyle McMartin]

AArch64 stores the frame pointer and return pointer, and decrements the
stack. Also remove my (no longer valid) email address.

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -13,7 +13,7 @@
 #  Random bits by Matt Mackall m...@selenic.com
 #  M68k port by Geert Uytterhoeven and Andreas Schwab
 #  AVR32 port by Haavard Skinnemoen (Atmel)
-#  PARISC port by Kyle McMartin k...@parisc-linux.org
+#  AArch64, PARISC ports by Kyle McMartin
 #  sparc port by Martin Habets errandir_n...@mph.eclipse.co.uk
 #
 #  Usage:
@@ -45,7 +45,10 @@ my (@stack, $re, $dre, $x, $xs, $funcre);
$x  = [0-9a-f];   # hex character
$xs = [0-9a-f ];  # hex character or space
$funcre = qr/^$x* (.*):$/;
-   if ($arch eq 'arm') {
+   if ($arch eq 'aarch64') {
+   #ffc0006325cc:   a9bb7bfdstp x29, x30, 
[sp,#-80]!
+   $re = qr/^.*stp.*sp,\#-([0-9]{1,8})\]\!/o;
+   } elsif ($arch eq 'arm') {
#c0008ffc:  e24dd064sub sp, sp, #100; 0x64
$re = qr/.*sub.*sp, sp, #(([0-9]{2}|[3-9])[0-9]{2})/o;
} elsif ($arch eq 'avr32') {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: don't set READ_IMPLIES_EXEC for EM_AARCH64

[Kyle McMartin]

On Thu, May 15, 2014 at 10:05:35AM +0100, Will Deacon wrote:
> Unfortunately, my understanding is that GCC currently requires this for
> nested functions, so this is an effective ABI breakage. On the plus side,
> the GCC guys are planning to fix that, so we should see PT_GNU_STACK getting
> used more frequently in the future.
> 

nested functions are a GNU extension, and aside from grub, I don't
think anyone really uses them. (At least, I certainly hope not.) Also,
ld.so already has a different idea from the kernel:
master@glibc:.% git grep DEFAULT_STACK_PERMS -- sysdeps/aarch64
(kyle@dreadnought:~/src/glibc)
sysdeps/aarch64/stackinfo.h:#define DEFAULT_STACK_PERMS (PF_R|PF_W)

ppc64 also does similarly, where they use the EXSTACK_DEFAULT in the
compat case, but their 64-bit ABI doesn't.

108 # define elf_read_implies_exec(ex, exec_stk) (is_32bit_task() ? \
109 (exec_stk == EXSTACK_DEFAULT) : 0)

I've submitted a gcc patch to emit .note.GNU-stack on AArch64 (which I
suspect was just an oversight initially.) Which will mean that anything
that puts code on the stack will be annotated to require executable
stacks.

And, frankly, I think it's kind of strange to have any of the personality
bits set by default.

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: don't set READ_IMPLIES_EXEC for EM_AARCH64

[Kyle McMartin]

On Thu, May 15, 2014 at 10:05:35AM +0100, Will Deacon wrote:
 Unfortunately, my understanding is that GCC currently requires this for
 nested functions, so this is an effective ABI breakage. On the plus side,
 the GCC guys are planning to fix that, so we should see PT_GNU_STACK getting
 used more frequently in the future.
 

nested functions are a GNU extension, and aside from grub, I don't
think anyone really uses them. (At least, I certainly hope not.) Also,
ld.so already has a different idea from the kernel:
master@glibc:.% git grep DEFAULT_STACK_PERMS -- sysdeps/aarch64
(kyle@dreadnought:~/src/glibc)
sysdeps/aarch64/stackinfo.h:#define DEFAULT_STACK_PERMS (PF_R|PF_W)

ppc64 also does similarly, where they use the EXSTACK_DEFAULT in the
compat case, but their 64-bit ABI doesn't.

108 # define elf_read_implies_exec(ex, exec_stk) (is_32bit_task() ? \
109 (exec_stk == EXSTACK_DEFAULT) : 0)

I've submitted a gcc patch to emit .note.GNU-stack on AArch64 (which I
suspect was just an oversight initially.) Which will mean that anything
that puts code on the stack will be annotated to require executable
stacks.

And, frankly, I think it's kind of strange to have any of the personality
bits set by default.

regards, Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: don't set READ_IMPLIES_EXEC for EM_AARCH64

[Kyle McMartin]

current->personality & READ_IMPLIES_EXEC is currently being set for
AArch64 binaries, resulting in an executable stack, when no explicit
PT_GNU_STACK header is present.

[kmcmarti@sedition ~]$ uname -p
aarch64
[kmcmarti@sedition ~]$ cat /proc/$$/personality 
0040

The reason for this is, without an explicit PT_GNU_STACK entry in the
binary, stk is still set to EXSTACK_DEFAULT (which should be
non-executable on AArch64.) As a result, elf_read_implies_exec is true,
and we set READ_IMPLIES_EXEC in binfmt_elf.c:load_elf_binary.

Fix this to return 0 in the native case, and parrot the logic from
arch/arm/kernel/elf.c otherwise. With this patch, binaries correctly
don't have READ_IMPLIES_EXEC set, and we can let PT_GNU_STACK change
things if it's explicitly requested.

Signed-off-by: Kyle McMartin 

--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -114,7 +114,8 @@ typedef struct user_fpsimd_state elf_fpregset_t;
  */
 #define elf_check_arch(x)  ((x)->e_machine == EM_AARCH64)
 
-#define elf_read_implies_exec(ex,stk)  (stk != EXSTACK_DISABLE_X)
+#define elf_read_implies_exec(ex,stk)  (test_thread_flag(TIF_32BIT) \
+? (stk == EXSTACK_ENABLE_X) : 0)
 
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE  PAGE_SIZE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: don't set READ_IMPLIES_EXEC for EM_AARCH64

[Kyle McMartin]

current-personality  READ_IMPLIES_EXEC is currently being set for
AArch64 binaries, resulting in an executable stack, when no explicit
PT_GNU_STACK header is present.

[kmcmarti@sedition ~]$ uname -p
aarch64
[kmcmarti@sedition ~]$ cat /proc/$$/personality 
0040

The reason for this is, without an explicit PT_GNU_STACK entry in the
binary, stk is still set to EXSTACK_DEFAULT (which should be
non-executable on AArch64.) As a result, elf_read_implies_exec is true,
and we set READ_IMPLIES_EXEC in binfmt_elf.c:load_elf_binary.

Fix this to return 0 in the native case, and parrot the logic from
arch/arm/kernel/elf.c otherwise. With this patch, binaries correctly
don't have READ_IMPLIES_EXEC set, and we can let PT_GNU_STACK change
things if it's explicitly requested.

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -114,7 +114,8 @@ typedef struct user_fpsimd_state elf_fpregset_t;
  */
 #define elf_check_arch(x)  ((x)-e_machine == EM_AARCH64)
 
-#define elf_read_implies_exec(ex,stk)  (stk != EXSTACK_DISABLE_X)
+#define elf_read_implies_exec(ex,stk)  (test_thread_flag(TIF_32BIT) \
+? (stk == EXSTACK_ENABLE_X) : 0)
 
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE  PAGE_SIZE
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] x32: use compat shims for io_{setup,submit}

[Kyle McMartin]

On Sun, May 04, 2014 at 08:43:15PM -0400, Mike Frysinger wrote:
> The io_setup takes a pointer to a context id of type aio_context_t.
> This in turn is typed to a __kernel_ulong_t.  We could tweak the
> exported headers to define this as a 64bit quantity for specific
> ABIs, but since we already have a 32bit compat shim for the x86 ABI,
> let's just re-use that logic.  The libaio package is also written to
> expect this as a pointer type, so a compat shim would simplify that.
> 
> The io_submit func operates on an array of pointers to iocb structs.
> Padding out the array to be 64bit aligned is a huge pain, so convert
> it over to the existing compat shim too.
> 
> We don't convert io_getevents to the compat func as its only purpose
> is to handle the timespec struct, and the x32 ABI uses 64bit times.
> 
> With this change, the libaio package can now pass its testsuite when
> built for the x32 ABI.
> 
> Signed-off-by: Mike Frysinger 

yeah, this looks like it should fix the issue in a much simpler way.
nice work Mike.

regards, Kyle

> ---
>  arch/x86/syscalls/syscall_64.tbl | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/syscalls/syscall_64.tbl 
> b/arch/x86/syscalls/syscall_64.tbl
> index 04376ac..ec255a1 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -212,10 +212,10 @@
>  203  common  sched_setaffinity   sys_sched_setaffinity
>  204  common  sched_getaffinity   sys_sched_getaffinity
>  205  64  set_thread_area
> -206  common  io_setupsys_io_setup
> +206  64  io_setupsys_io_setup
>  207  common  io_destroy  sys_io_destroy
>  208  common  io_geteventssys_io_getevents
> -209  common  io_submit   sys_io_submit
> +209  64  io_submit   sys_io_submit
>  210  common  io_cancel   sys_io_cancel
>  211  64  get_thread_area
>  212  common  lookup_dcookie  sys_lookup_dcookie
> @@ -359,3 +359,5 @@
>  540  x32 process_vm_writev   compat_sys_process_vm_writev
>  541  x32 setsockopt  compat_sys_setsockopt
>  542  x32 getsockopt  compat_sys_getsockopt
> +543  x32 io_setupcompat_sys_io_setup
> +544  x32 io_submit   compat_sys_io_submit
> -- 
> 1.9.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x32: use compat shims for io_{setup,submit}

[Kyle McMartin]

On Sun, May 04, 2014 at 08:43:15PM -0400, Mike Frysinger wrote:
 The io_setup takes a pointer to a context id of type aio_context_t.
 This in turn is typed to a __kernel_ulong_t.  We could tweak the
 exported headers to define this as a 64bit quantity for specific
 ABIs, but since we already have a 32bit compat shim for the x86 ABI,
 let's just re-use that logic.  The libaio package is also written to
 expect this as a pointer type, so a compat shim would simplify that.
 
 The io_submit func operates on an array of pointers to iocb structs.
 Padding out the array to be 64bit aligned is a huge pain, so convert
 it over to the existing compat shim too.
 
 We don't convert io_getevents to the compat func as its only purpose
 is to handle the timespec struct, and the x32 ABI uses 64bit times.
 
 With this change, the libaio package can now pass its testsuite when
 built for the x32 ABI.
 
 Signed-off-by: Mike Frysinger vap...@gentoo.org

yeah, this looks like it should fix the issue in a much simpler way.
nice work Mike.

regards, Kyle

 ---
  arch/x86/syscalls/syscall_64.tbl | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/arch/x86/syscalls/syscall_64.tbl 
 b/arch/x86/syscalls/syscall_64.tbl
 index 04376ac..ec255a1 100644
 --- a/arch/x86/syscalls/syscall_64.tbl
 +++ b/arch/x86/syscalls/syscall_64.tbl
 @@ -212,10 +212,10 @@
  203  common  sched_setaffinity   sys_sched_setaffinity
  204  common  sched_getaffinity   sys_sched_getaffinity
  205  64  set_thread_area
 -206  common  io_setupsys_io_setup
 +206  64  io_setupsys_io_setup
  207  common  io_destroy  sys_io_destroy
  208  common  io_geteventssys_io_getevents
 -209  common  io_submit   sys_io_submit
 +209  64  io_submit   sys_io_submit
  210  common  io_cancel   sys_io_cancel
  211  64  get_thread_area
  212  common  lookup_dcookie  sys_lookup_dcookie
 @@ -359,3 +359,5 @@
  540  x32 process_vm_writev   compat_sys_process_vm_writev
  541  x32 setsockopt  compat_sys_setsockopt
  542  x32 getsockopt  compat_sys_getsockopt
 +543  x32 io_setupcompat_sys_io_setup
 +544  x32 io_submit   compat_sys_io_submit
 -- 
 1.9.2
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xz: Enable all filters by default in Kconfig

[Kyle McMartin]

On Wed, Mar 05, 2014 at 07:30:57PM +0200, Lasse Collin wrote:
> From: Lasse Collin 
> 
> This restores the old behavior that existed before 2013-02-22.
> Disabling the filters only makes sense on embedded systems.
> 
> Signed-off-by: Lasse Collin 

I'm happy with that compromise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xz: Enable all filters by default in Kconfig

[Kyle McMartin]

On Wed, Mar 05, 2014 at 07:30:57PM +0200, Lasse Collin wrote:
 From: Lasse Collin lasse.col...@tukaani.org
 
 This restores the old behavior that existed before 2013-02-22.
 Disabling the filters only makes sense on embedded systems.
 
 Signed-off-by: Lasse Collin lasse.col...@tukaani.org

I'm happy with that compromise.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] xz: make XZ_DEC_BCJ filters non-optional

[Kyle McMartin]

From: Kyle McMartin 

Having these optional is more trouble than is justified by the
negligible increase in code size to lib/xz/ if they're all compiled in.
Their optional status ends up necessitating rebuilds of the kernel
in order to be able to decompress XZ-compressed squashfs images which
use non-native BCJ filters (ie: you need to enable XZ_DEC_POWERPC on
x86_64 in order to loop-mount a ppc64 squashfs that uses it.)

So save ourselves the trouble and build them all into xz_dec_bcj.o to
begin with. (I could conceivably see a case where CONFIG_EXPERT made
these selectable, but again, even on embedded platforms, the .text
increase we're talking about is noise...)

textdatabss dec hex filename
12390   0   12394d7 xz_dec_bcj.o
22630   0   22638d7 xz_dec_bcj.o.2

regards, Kyle

Signed-off-by: Kyle McMartin 

--- a/lib/xz/Kconfig
+++ b/lib/xz/Kconfig
@@ -6,44 +6,6 @@ config XZ_DEC
  the .xz file format as the container. For integrity checking,
  CRC32 is supported. See Documentation/xz.txt for more information.
 
-if XZ_DEC
-
-config XZ_DEC_X86
-   bool "x86 BCJ filter decoder"
-   default y if X86
-   select XZ_DEC_BCJ
-
-config XZ_DEC_POWERPC
-   bool "PowerPC BCJ filter decoder"
-   default y if PPC
-   select XZ_DEC_BCJ
-
-config XZ_DEC_IA64
-   bool "IA-64 BCJ filter decoder"
-   default y if IA64
-   select XZ_DEC_BCJ
-
-config XZ_DEC_ARM
-   bool "ARM BCJ filter decoder"
-   default y if ARM
-   select XZ_DEC_BCJ
-
-config XZ_DEC_ARMTHUMB
-   bool "ARM-Thumb BCJ filter decoder"
-   default y if (ARM && ARM_THUMB)
-   select XZ_DEC_BCJ
-
-config XZ_DEC_SPARC
-   bool "SPARC BCJ filter decoder"
-   default y if SPARC
-   select XZ_DEC_BCJ
-
-endif
-
-config XZ_DEC_BCJ
-   bool
-   default n
-
 config XZ_DEC_TEST
tristate "XZ decompressor tester"
default n
diff --git a/lib/xz/Makefile b/lib/xz/Makefile
index a7fa769..4f209f7 100644
--- a/lib/xz/Makefile
+++ b/lib/xz/Makefile
@@ -1,5 +1,4 @@
 obj-$(CONFIG_XZ_DEC) += xz_dec.o
-xz_dec-y := xz_dec_syms.o xz_dec_stream.o xz_dec_lzma2.o
-xz_dec-$(CONFIG_XZ_DEC_BCJ) += xz_dec_bcj.o
+xz_dec-y := xz_dec_syms.o xz_dec_stream.o xz_dec_lzma2.o xz_dec_bcj.o
 
 obj-$(CONFIG_XZ_DEC_TEST) += xz_dec_test.o
diff --git a/lib/xz/xz_dec_bcj.c b/lib/xz/xz_dec_bcj.c
index a768e6d..e2ac55c 100644
--- a/lib/xz/xz_dec_bcj.c
+++ b/lib/xz/xz_dec_bcj.c
@@ -10,12 +10,6 @@
 
 #include "xz_private.h"
 
-/*
- * The rest of the file is inside this ifdef. It makes things a little more
- * convenient when building without support for any BCJ filters.
- */
-#ifdef XZ_DEC_BCJ
-
 struct xz_dec_bcj {
/* Type of the BCJ filter being used */
enum {
@@ -75,7 +69,6 @@ struct xz_dec_bcj {
} temp;
 };
 
-#ifdef XZ_DEC_X86
 /*
  * This is used to test the most significant byte of a memory address
  * in an x86 instruction.
@@ -154,9 +147,7 @@ static size_t bcj_x86(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
s->x86_prev_mask = prev_pos > 3 ? 0 : prev_mask << (prev_pos - 1);
return i;
 }
-#endif
 
-#ifdef XZ_DEC_POWERPC
 static size_t bcj_powerpc(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -175,9 +166,7 @@ static size_t bcj_powerpc(struct xz_dec_bcj *s, uint8_t 
*buf, size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_IA64
 static size_t bcj_ia64(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
static const uint8_t branch_table[32] = {
@@ -259,9 +248,7 @@ static size_t bcj_ia64(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_ARM
 static size_t bcj_arm(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -282,9 +269,7 @@ static size_t bcj_arm(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_ARMTHUMB
 static size_t bcj_armthumb(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -310,9 +295,7 @@ static size_t bcj_armthumb(struct xz_dec_bcj *s, uint8_t 
*buf, size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_SPARC
 static size_t bcj_sparc(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -332,7 +315,6 @@ static size_t bcj_sparc(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
 
return i;
 }
-#endif
 
 /*
  * Apply the selected BCJ filter. Update *pos and s->pos to match the amount
@@ -351,36 +333,24 @@ static void bcj_apply(struct xz_dec_bcj *s,
size -= *pos;
 
switch (s->type) {
-#ifdef XZ_DEC_X86
case BCJ_X86:
filtered = bcj_x86(s, buf, size);
break;
-#endif
-#ifdef XZ_DEC_POWERPC
case BCJ_POWERPC:
filtered = bcj_powerpc(s, buf, size);
break;
-#endif
-#ifdef X

[PATCH] xz: make XZ_DEC_BCJ filters non-optional

[Kyle McMartin]

From: Kyle McMartin k...@redhat.com

Having these optional is more trouble than is justified by the
negligible increase in code size to lib/xz/ if they're all compiled in.
Their optional status ends up necessitating rebuilds of the kernel
in order to be able to decompress XZ-compressed squashfs images which
use non-native BCJ filters (ie: you need to enable XZ_DEC_POWERPC on
x86_64 in order to loop-mount a ppc64 squashfs that uses it.)

So save ourselves the trouble and build them all into xz_dec_bcj.o to
begin with. (I could conceivably see a case where CONFIG_EXPERT made
these selectable, but again, even on embedded platforms, the .text
increase we're talking about is noise...)

textdatabss dec hex filename
12390   0   12394d7 xz_dec_bcj.o
22630   0   22638d7 xz_dec_bcj.o.2

regards, Kyle

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/lib/xz/Kconfig
+++ b/lib/xz/Kconfig
@@ -6,44 +6,6 @@ config XZ_DEC
  the .xz file format as the container. For integrity checking,
  CRC32 is supported. See Documentation/xz.txt for more information.
 
-if XZ_DEC
-
-config XZ_DEC_X86
-   bool x86 BCJ filter decoder
-   default y if X86
-   select XZ_DEC_BCJ
-
-config XZ_DEC_POWERPC
-   bool PowerPC BCJ filter decoder
-   default y if PPC
-   select XZ_DEC_BCJ
-
-config XZ_DEC_IA64
-   bool IA-64 BCJ filter decoder
-   default y if IA64
-   select XZ_DEC_BCJ
-
-config XZ_DEC_ARM
-   bool ARM BCJ filter decoder
-   default y if ARM
-   select XZ_DEC_BCJ
-
-config XZ_DEC_ARMTHUMB
-   bool ARM-Thumb BCJ filter decoder
-   default y if (ARM  ARM_THUMB)
-   select XZ_DEC_BCJ
-
-config XZ_DEC_SPARC
-   bool SPARC BCJ filter decoder
-   default y if SPARC
-   select XZ_DEC_BCJ
-
-endif
-
-config XZ_DEC_BCJ
-   bool
-   default n
-
 config XZ_DEC_TEST
tristate XZ decompressor tester
default n
diff --git a/lib/xz/Makefile b/lib/xz/Makefile
index a7fa769..4f209f7 100644
--- a/lib/xz/Makefile
+++ b/lib/xz/Makefile
@@ -1,5 +1,4 @@
 obj-$(CONFIG_XZ_DEC) += xz_dec.o
-xz_dec-y := xz_dec_syms.o xz_dec_stream.o xz_dec_lzma2.o
-xz_dec-$(CONFIG_XZ_DEC_BCJ) += xz_dec_bcj.o
+xz_dec-y := xz_dec_syms.o xz_dec_stream.o xz_dec_lzma2.o xz_dec_bcj.o
 
 obj-$(CONFIG_XZ_DEC_TEST) += xz_dec_test.o
diff --git a/lib/xz/xz_dec_bcj.c b/lib/xz/xz_dec_bcj.c
index a768e6d..e2ac55c 100644
--- a/lib/xz/xz_dec_bcj.c
+++ b/lib/xz/xz_dec_bcj.c
@@ -10,12 +10,6 @@
 
 #include xz_private.h
 
-/*
- * The rest of the file is inside this ifdef. It makes things a little more
- * convenient when building without support for any BCJ filters.
- */
-#ifdef XZ_DEC_BCJ
-
 struct xz_dec_bcj {
/* Type of the BCJ filter being used */
enum {
@@ -75,7 +69,6 @@ struct xz_dec_bcj {
} temp;
 };
 
-#ifdef XZ_DEC_X86
 /*
  * This is used to test the most significant byte of a memory address
  * in an x86 instruction.
@@ -154,9 +147,7 @@ static size_t bcj_x86(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
s-x86_prev_mask = prev_pos  3 ? 0 : prev_mask  (prev_pos - 1);
return i;
 }
-#endif
 
-#ifdef XZ_DEC_POWERPC
 static size_t bcj_powerpc(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -175,9 +166,7 @@ static size_t bcj_powerpc(struct xz_dec_bcj *s, uint8_t 
*buf, size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_IA64
 static size_t bcj_ia64(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
static const uint8_t branch_table[32] = {
@@ -259,9 +248,7 @@ static size_t bcj_ia64(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_ARM
 static size_t bcj_arm(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -282,9 +269,7 @@ static size_t bcj_arm(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_ARMTHUMB
 static size_t bcj_armthumb(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -310,9 +295,7 @@ static size_t bcj_armthumb(struct xz_dec_bcj *s, uint8_t 
*buf, size_t size)
 
return i;
 }
-#endif
 
-#ifdef XZ_DEC_SPARC
 static size_t bcj_sparc(struct xz_dec_bcj *s, uint8_t *buf, size_t size)
 {
size_t i;
@@ -332,7 +315,6 @@ static size_t bcj_sparc(struct xz_dec_bcj *s, uint8_t *buf, 
size_t size)
 
return i;
 }
-#endif
 
 /*
  * Apply the selected BCJ filter. Update *pos and s-pos to match the amount
@@ -351,36 +333,24 @@ static void bcj_apply(struct xz_dec_bcj *s,
size -= *pos;
 
switch (s-type) {
-#ifdef XZ_DEC_X86
case BCJ_X86:
filtered = bcj_x86(s, buf, size);
break;
-#endif
-#ifdef XZ_DEC_POWERPC
case BCJ_POWERPC:
filtered = bcj_powerpc(s, buf, size);
break;
-#endif
-#ifdef XZ_DEC_IA64
case BCJ_IA64:
filtered = bcj_ia64(s, buf, size

[PATCH] r8169: initialize rtl8169_stats seqlock

[Kyle McMartin]

From: Kyle McMartin 

Boris reports he's seeing:
> [9.195943] INFO: trying to register non-static key.
> [9.196031] the code is fine but needs lockdep annotation.
> [9.196031] turning off the locking correctness validator.
> [9.196031] CPU: 1 PID: 933 Comm: modprobe Not tainted 3.14.0-rc4+ #1
with the r8169 driver.

These are occuring because the seqcount embedded in u64_stats_sync on
32-bit SMP is uninitialized which is making lockdep unhappy.

Signed-off-by: Kyle McMartin 

---

Patch is only compile tested by me, as these initializers will disappear
on 64-bit.

--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7118,6 +7118,8 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
 
mutex_init(>wk.mutex);
+   u64_stats_init(>rx_stats.syncp);
+   u64_stats_init(>tx_stats.syncp);
 
/* Get MAC address */
for (i = 0; i < ETH_ALEN; i++)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/usb: Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver

[Kyle McMartin]

On Mon, Feb 24, 2014 at 03:13:49PM -0800, Keith Packard wrote:
> +static const struct driver_info lenovo_info = {

> +}, {
> + /* Lenovo ThinkPad OneLink GigaLAN */
> + USB_DEVICE(0x17ef, 0x304b),
> + .driver_info = (unsigned long)_info,

_info, surely.

--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/usb: Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver

[Kyle McMartin]

On Mon, Feb 24, 2014 at 03:13:49PM -0800, Keith Packard wrote:
 +static const struct driver_info lenovo_info = {
snip
 +}, {
 + /* Lenovo ThinkPad OneLink GigaLAN */
 + USB_DEVICE(0x17ef, 0x304b),
 + .driver_info = (unsigned long)samsung_info,

lenovo_info, surely.

--Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] r8169: initialize rtl8169_stats seqlock

[Kyle McMartin]

From: Kyle McMartin k...@redhat.com

Boris reports he's seeing:
 [9.195943] INFO: trying to register non-static key.
 [9.196031] the code is fine but needs lockdep annotation.
 [9.196031] turning off the locking correctness validator.
 [9.196031] CPU: 1 PID: 933 Comm: modprobe Not tainted 3.14.0-rc4+ #1
with the r8169 driver.

These are occuring because the seqcount embedded in u64_stats_sync on
32-bit SMP is uninitialized which is making lockdep unhappy.

Signed-off-by: Kyle McMartin k...@redhat.com

---

Patch is only compile tested by me, as these initializers will disappear
on 64-bit.

--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7118,6 +7118,8 @@ rtl_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
 
mutex_init(tp-wk.mutex);
+   u64_stats_init(tp-rx_stats.syncp);
+   u64_stats_init(tp-tx_stats.syncp);
 
/* Get MAC address */
for (i = 0; i  ETH_ALEN; i++)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm/Kconfig.debug: CONFIG_DEBUG_SET_MODULE_RONX and insn patching are mutually exclusive

[Kyle McMartin]

With both options set, we're seeing an Oops while loading bridge.ko, as
netfilter is trying to use jump labels on the module .text after it's
been marked read-only. I'll cook up a patch to do what X86 does and
remap the page read-write while it's being patched, but for 3.14, we
should mark them as exclusive so others don't hit this crash.

Signed-off-by: Kyle McMartin 

--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1197,7 +1197,7 @@ config PID_IN_CONTEXTIDR
 
 config DEBUG_SET_MODULE_RONX
bool "Set loadable kernel module data as NX and text as RO"
-   depends on MODULES
+   depends on MODULES && !(JUMP_LABEL || KPROBES)
---help---
  This option helps catch unintended modifications to loadable
  kernel module's text and read-only data. It also prevents execution
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm/Kconfig.debug: CONFIG_DEBUG_SET_MODULE_RONX and insn patching are mutually exclusive

[Kyle McMartin]

With both options set, we're seeing an Oops while loading bridge.ko, as
netfilter is trying to use jump labels on the module .text after it's
been marked read-only. I'll cook up a patch to do what X86 does and
remap the page read-write while it's being patched, but for 3.14, we
should mark them as exclusive so others don't hit this crash.

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1197,7 +1197,7 @@ config PID_IN_CONTEXTIDR
 
 config DEBUG_SET_MODULE_RONX
bool Set loadable kernel module data as NX and text as RO
-   depends on MODULES
+   depends on MODULES  !(JUMP_LABEL || KPROBES)
---help---
  This option helps catch unintended modifications to loadable
  kernel module's text and read-only data. It also prevents execution
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: fix strnlen_user when count <= strlen

[Kyle McMartin]

On Fri, Jan 17, 2014 at 10:51:07AM +, Will Deacon wrote:
> Actually, I have removed strnlen_user for 3.14. Could you try your test case
> with our for-next branch please?
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> 

This will work fine, I believe (I can't easily test on HW since we're
dependent on $vendor drivers that aren't upstream yet) but in my testing
yesterday I parroted the x86 word-at-a-time.h and lib/strnlen_user.c and
that seemed to work.

> As for the issue you spotted, we probably need a fix for that to go into
> stable kernels. Does the following (smaller patch) work for you?
> 

This gets the count == 0 case wrong still, I believe.

=== count = 0 ===
strnlen_user = 0
__strnlen_user = 1

(Where strnlen_user is the lib/strnlen_user.c implementation.)

Testing if (n <= 0) return 0; before __strnlen_user fixes it though.

Given this is called in, I think, only two places in the kernel, maybe
we should just backport the switch to generic for stable? I can't
imagine it conflicting with anything.

regards, Kyle

> Will
> 
> --->8
> 
> diff --git a/arch/arm64/lib/strnlen_user.S b/arch/arm64/lib/strnlen_user.S
> index 7f7b176a5646..73f3335a2a45 100644
> --- a/arch/arm64/lib/strnlen_user.S
> +++ b/arch/arm64/lib/strnlen_user.S
> @@ -37,6 +37,7 @@ ENTRY(__strnlen_user)
>  USER(9f, ldrbw3, [x0], #1)
>   cbnzw3, 1b
>  2:   sub x0, x0, x2
> + cincx0, x0, mi
>   ret
>  ENDPROC(__strnlen_user)
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: fix strnlen_user when count = strlen

[Kyle McMartin]

On Fri, Jan 17, 2014 at 10:51:07AM +, Will Deacon wrote:
 Actually, I have removed strnlen_user for 3.14. Could you try your test case
 with our for-next branch please?
 
   git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
 

This will work fine, I believe (I can't easily test on HW since we're
dependent on $vendor drivers that aren't upstream yet) but in my testing
yesterday I parroted the x86 word-at-a-time.h and lib/strnlen_user.c and
that seemed to work.

 As for the issue you spotted, we probably need a fix for that to go into
 stable kernels. Does the following (smaller patch) work for you?
 

This gets the count == 0 case wrong still, I believe.

=== count = 0 ===
strnlen_user = 0
__strnlen_user = 1

(Where strnlen_user is the lib/strnlen_user.c implementation.)

Testing if (n = 0) return 0; before __strnlen_user fixes it though.

Given this is called in, I think, only two places in the kernel, maybe
we should just backport the switch to generic for stable? I can't
imagine it conflicting with anything.

regards, Kyle

 Will
 
 ---8
 
 diff --git a/arch/arm64/lib/strnlen_user.S b/arch/arm64/lib/strnlen_user.S
 index 7f7b176a5646..73f3335a2a45 100644
 --- a/arch/arm64/lib/strnlen_user.S
 +++ b/arch/arm64/lib/strnlen_user.S
 @@ -37,6 +37,7 @@ ENTRY(__strnlen_user)
  USER(9f, ldrbw3, [x0], #1)
   cbnzw3, 1b
  2:   sub x0, x0, x2
 + cincx0, x0, mi
   ret
  ENDPROC(__strnlen_user)
  
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: fix strnlen_user when count <= strlen

[Kyle McMartin]

I received a bug report about the ruby test-suite failing on AArch64 when
attempting to pass MAX_ARG_STRLEN sized args to execv[1]. It was
expecting an E2BIG returned, but instead was receiving ENOMEM, and
concatenating the argument strings in funky ways.

The problem appeared to be in __strnlen_user on arm64, as when
instrumenting fs/exec.c to compare the results of the asm-generic
strnlen_user, I noticed an off-by-one on the result:
long-param-test: optimized strnlen_user (131072) and naive (131073) disagree!

As a result, fix strnlen_user to match expected behaviour as documented
in lib/strnlen_user.c, and return count+1 when count would be exceeded.

I didn't feel comfortable prodding the assembler, so I just worked
around it in the wrapper.

Signed-off-by: Kyle McMartin 

1. https://bugzilla.redhat.com/show_bug.cgi?id=1038676

---

I tested that this behaves the same as the lib/strnlen_user.c version
with some hacked together code here:
http://kyle.fedorapeople.org/strnlen_user-test.tar.xz

{master}kmcmarti ~/strnlen_user-test $ ./test
=== count = 0 ===
strnlen_user = 0
__strnlen_user = 0
fixed__strnlen_user = 0
=== count < strlen ===
strnlen_user = 7
__strnlen_user = 6
fixed__strnlen_user = 7
=== count = strlen ===
strnlen_user = 13
__strnlen_user = 12
fixed__strnlen_user = 13
=== count > strlen ===
strnlen_user = 13
__strnlen_user = 13
fixed__strnlen_user = 13

--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -290,9 +290,15 @@ static inline long __must_check strnlen_user(const char 
__user *s, long n)
 {
unsigned long res = 0;
 
+   if (unlikely(n <= 0))
+   return 0;
+
if (__addr_ok(s))
res = __strnlen_user(s, n);
 
+   if (unlikely(res >= n))
+   return n + 1;
+
return res;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] aarch64: always map VDSO at worst case alignment

[Kyle McMartin]

On Thu, Jan 16, 2014 at 12:53:18PM -0500, Kyle McMartin wrote:
> I'll reboot a machine with this fix to test it as soon as possible.
> 
> Acked-by: Kyle McMartin 
> 

Yeah, looks to work properly, although I didn't test 64K pages in the
simulator.

--Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] aarch64: always map VDSO at worst case alignment

[Kyle McMartin]

On Thu, Jan 16, 2014 at 05:43:44PM +, Will Deacon wrote:
> > +   struct vm_unmapped_area_info info =
> > +   {
> > +   .flags = 0,
> > +   .length = vdso_mapping_len,
> > +   .low_limit = mm->mmap_base,
> > +   .high_limit = TASK_SIZE,
> > +   .align_mask = (1 << 16) - 1,
> > +   };
> > +   vdso_base = vm_unmapped_area();
> > +   }
> 
> I don't like this fix. The kernel is perfectly alright mapping the vdso at
> the actual page size, as opposed to the maximum. Since the vdso isn't
> demand-paged, we can actually just tell the linker not to bother forcing 64k
> (worst case) alignment for PT_LOAD segments. Please can you try the patch
> below?
> 

Me either, tbh. ;-)

I was testing out using -Wl,-z,max-page-size for the
!CONFIG_ARM64_64K_PAGES case, and that seemed to work. A quick compile
check shows the segment alignment being 0x10 with -Wl,-n:

kmcmarti ~/linux $ eu-readelf -l
arch/arm64/kernel/vdso/vdso.so
Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz
MemSiz   Flg Align
  LOAD   0x00 0x 0x 0x000700
0x000700 R E 0x10

so I think that should work nicely!

I'll reboot a machine with this fix to test it as soon as possible.

Acked-by: Kyle McMartin 

> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -48,7 +48,7 @@ $(obj-vdso): %.o: %.S
>  
>  # Actual build commands
>  quiet_cmd_vdsold = VDSOL $@
> -  cmd_vdsold = $(CC) $(c_flags) -Wl,-T $^ -o $@
> +  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
>  quiet_cmd_vdsoas = VDSOA $@
>cmd_vdsoas = $(CC) $(a_flags) -c -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] aarch64: always map VDSO at worst case alignment

[Kyle McMartin]

On Thu, Jan 16, 2014 at 05:43:44PM +, Will Deacon wrote:
  +   struct vm_unmapped_area_info info =
  +   {
  +   .flags = 0,
  +   .length = vdso_mapping_len,
  +   .low_limit = mm-mmap_base,
  +   .high_limit = TASK_SIZE,
  +   .align_mask = (1  16) - 1,
  +   };
  +   vdso_base = vm_unmapped_area(info);
  +   }
 
 I don't like this fix. The kernel is perfectly alright mapping the vdso at
 the actual page size, as opposed to the maximum. Since the vdso isn't
 demand-paged, we can actually just tell the linker not to bother forcing 64k
 (worst case) alignment for PT_LOAD segments. Please can you try the patch
 below?
 

Me either, tbh. ;-)

I was testing out using -Wl,-z,max-page-size for the
!CONFIG_ARM64_64K_PAGES case, and that seemed to work. A quick compile
check shows the segment alignment being 0x10 with -Wl,-n:

kmcmarti ~/linux $ eu-readelf -l
arch/arm64/kernel/vdso/vdso.so
Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz
MemSiz   Flg Align
  LOAD   0x00 0x 0x 0x000700
0x000700 R E 0x10

so I think that should work nicely!

I'll reboot a machine with this fix to test it as soon as possible.

Acked-by: Kyle McMartin k...@redhat.com

 --- a/arch/arm64/kernel/vdso/Makefile
 +++ b/arch/arm64/kernel/vdso/Makefile
 @@ -48,7 +48,7 @@ $(obj-vdso): %.o: %.S
  
  # Actual build commands
  quiet_cmd_vdsold = VDSOL $@
 -  cmd_vdsold = $(CC) $(c_flags) -Wl,-T $^ -o $@
 +  cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
  quiet_cmd_vdsoas = VDSOA $@
cmd_vdsoas = $(CC) $(a_flags) -c -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] aarch64: always map VDSO at worst case alignment

[Kyle McMartin]

On Thu, Jan 16, 2014 at 12:53:18PM -0500, Kyle McMartin wrote:
 I'll reboot a machine with this fix to test it as soon as possible.
 
 Acked-by: Kyle McMartin k...@redhat.com
 

Yeah, looks to work properly, although I didn't test 64K pages in the
simulator.

--Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] arm64: fix strnlen_user when count = strlen

[Kyle McMartin]

I received a bug report about the ruby test-suite failing on AArch64 when
attempting to pass MAX_ARG_STRLEN sized args to execv[1]. It was
expecting an E2BIG returned, but instead was receiving ENOMEM, and
concatenating the argument strings in funky ways.

The problem appeared to be in __strnlen_user on arm64, as when
instrumenting fs/exec.c to compare the results of the asm-generic
strnlen_user, I noticed an off-by-one on the result:
long-param-test: optimized strnlen_user (131072) and naive (131073) disagree!

As a result, fix strnlen_user to match expected behaviour as documented
in lib/strnlen_user.c, and return count+1 when count would be exceeded.

I didn't feel comfortable prodding the assembler, so I just worked
around it in the wrapper.

Signed-off-by: Kyle McMartin k...@redhat.com

1. https://bugzilla.redhat.com/show_bug.cgi?id=1038676

---

I tested that this behaves the same as the lib/strnlen_user.c version
with some hacked together code here:
http://kyle.fedorapeople.org/strnlen_user-test.tar.xz

{master}kmcmarti ~/strnlen_user-test $ ./test
=== count = 0 ===
strnlen_user = 0
__strnlen_user = 0
fixed__strnlen_user = 0
=== count  strlen ===
strnlen_user = 7
__strnlen_user = 6
fixed__strnlen_user = 7
=== count = strlen ===
strnlen_user = 13
__strnlen_user = 12
fixed__strnlen_user = 13
=== count  strlen ===
strnlen_user = 13
__strnlen_user = 13
fixed__strnlen_user = 13

--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -290,9 +290,15 @@ static inline long __must_check strnlen_user(const char 
__user *s, long n)
 {
unsigned long res = 0;
 
+   if (unlikely(n = 0))
+   return 0;
+
if (__addr_ok(s))
res = __strnlen_user(s, n);
 
+   if (unlikely(res = n))
+   return n + 1;
+
return res;
 }
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] aarch64: always map VDSO at worst case alignment

[Kyle McMartin]

Currently on ARM64 with 4K pages set, GDB fails to load the VDSO with
the error "Failed to read a valid object file image from memory" as it
is applying the phdr alignment to the vma, and attempting to read below
where the VDSO is mapped. This is because our segment alignment is 64K
in the ELF headers, but the VDSO only has PAGE_SIZE alignment from
get_unmapped_area.

Work around this by calling vm_unmapped_area directly, and specifying
the worst case alignment (64K) directly.

With this patch applied, I no longer have issues loading the VDSO in
gdb (and no more error message every time I run a program inside it.)

Signed-off-by: Kyle McMartin 

--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -163,7 +163,18 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
vdso_mapping_len = (vdso_pages + 1) << PAGE_SHIFT;
 
down_write(>mmap_sem);
-   vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0);
+   {
+   /* the VDSO must be worst-case aligned to 64K */
+   struct vm_unmapped_area_info info =
+   {
+   .flags = 0,
+   .length = vdso_mapping_len,
+   .low_limit = mm->mmap_base,
+   .high_limit = TASK_SIZE,
+   .align_mask = (1 << 16) - 1,
+   };
+   vdso_base = vm_unmapped_area();
+   }
if (IS_ERR_VALUE(vdso_base)) {
ret = vdso_base;
goto up_fail;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] aarch64: always map VDSO at worst case alignment

[Kyle McMartin]

Currently on ARM64 with 4K pages set, GDB fails to load the VDSO with
the error Failed to read a valid object file image from memory as it
is applying the phdr alignment to the vma, and attempting to read below
where the VDSO is mapped. This is because our segment alignment is 64K
in the ELF headers, but the VDSO only has PAGE_SIZE alignment from
get_unmapped_area.

Work around this by calling vm_unmapped_area directly, and specifying
the worst case alignment (64K) directly.

With this patch applied, I no longer have issues loading the VDSO in
gdb (and no more error message every time I run a program inside it.)

Signed-off-by: Kyle McMartin k...@redhat.com

--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -163,7 +163,18 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
vdso_mapping_len = (vdso_pages + 1)  PAGE_SHIFT;
 
down_write(mm-mmap_sem);
-   vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0);
+   {
+   /* the VDSO must be worst-case aligned to 64K */
+   struct vm_unmapped_area_info info =
+   {
+   .flags = 0,
+   .length = vdso_mapping_len,
+   .low_limit = mm-mmap_base,
+   .high_limit = TASK_SIZE,
+   .align_mask = (1  16) - 1,
+   };
+   vdso_base = vm_unmapped_area(info);
+   }
if (IS_ERR_VALUE(vdso_base)) {
ret = vdso_base;
goto up_fail;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] kernel: add support for init_array constructors

[Kyle McMartin]

On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
> I'm not sure if coexistence of .ctors and .init_array sections should result 
> in
> denial of module, but I for sure know nothing about this :). Could you maybe
> privide one example of the "weird thing"?
> 

They shouldn't exist unless placed there intentionally... I suspect a
call_if_changed Makefile target to regenerated a header would solve this
problem sufficiently for a given toolchain version.

A little exposition:
.init_array and .ctors are laid out on top of each other, with an
ordering that's a bit complicated... the sort of the ctor functions ends
up being .ctor.x upwards towards 65535, and .init_array.x downwards
from 65535 towards 0, with priority 65535-x, so that

.init_array.32768 would be called before .ctor.32768.

It's all a complete mess.

Perhaps if CONFIG_GCOV is on, we should enforce MODVERSIONS and make
sure the GCC version doesn't change for the running kernel?

Maybe it would be sufficient to just detect what the toolchain supports
and do that? I have a patch based on the configure.ac in gcc that
does something like that, which would be trivial to use to generate a
header based on gcc version.

> Anyway many thanks for taking time to look at this. Below is my attepmt to
> implement the check you proposed. 
> 
> untested/uncompiled

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/