linux.kernel - 26 new messages in 9 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/7ef1fd3272ca31e9?hl=en
* x86: make reboot task only run on the appropriate processor - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/106a90092227cfd4?hl=en
* module.h: Remove unnecessary semicolon - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/21d44c8ae1bfdf4a?hl=en
* cifs: Use data structures to compute NTLMv2 response offsets - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/acd5fb058fd9bf01?hl=en
* ARM: pxa/colibri: fix build with CONFIG_USB_OHCI_HCD=y - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/3197e83cdd7d7357?hl=en
* PCI: Introduce two new MSI infrastructure calls for masking/unmasking. - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/eba2e16e7822fca1?hl=en
* linux-next: manual merge of the block tree with the tree - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/48082f7232e087c4?hl=en
* staging: zsmalloc: Ensure handle is never 0 on success - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/56e7b28ac067dee2?hl=en
* Staging: sb105x: info leak in mp_get_count() - 16 messages, 1 author
http://groups.google.com/group/linux.kernel/t/33787d3f6e3e1d33?hl=en

==============================================================================
TOPIC: ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
http://groups.google.com/group/linux.kernel/t/7ef1fd3272ca31e9?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Nov 7 2013 5:40 pm
From: Rob Herring


On Thu, Nov 7, 2013 at 1:20 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> If we're running on a v7 ARM CPU, detect if the CPU supports the
> sdiv/udiv instructions and replace the signed and unsigned
> division library functions with an sdiv/udiv instruction.

[snip]

> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index bd454b0..6ed6496 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -15,6 +15,9 @@ lib-y := backtrace.o changebit.o csumipv6.o csumpartial.o \
> io-readsb.o io-writesb.o io-readsl.o io-writesl.o \
> call_with_stack.o
>
> +lib-$(CONFIG_CPU_V7) += div-v7.o
> +CFLAGS_div-v7.o := -march=armv7-a

Won't this fail to build if the compiler doesn't have armv7-a support.
Perhaps we don't care about compilers that old.

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





==============================================================================
TOPIC: x86: make reboot task only run on the appropriate processor
http://groups.google.com/group/linux.kernel/t/106a90092227cfd4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Nov 7 2013 5:40 pm
From: Dave Young


On 11/05/13 at 05:16pm, Baoquan He wrote:
> Currently system always reboot after below message when execute "kexec -e".
>
> [ 0.572119] smpboot: Booting Node 0, Processors # 1 OK
>
> In commit 1b3a5d02ee070c8f9943333b9b6370f486601e0f, reboot= handling was
> moved to kerne/reboot.c. However, the code to migrate current thread to
> reboot cpu was removed. That cause this incorrect kexec behavior.
>
> Now add that code block back.

quote a mail from Thomas Renninger <trenn@suse.de>:
Answer his questions here.

> > For the smp boot issue I think there's nothing to do with dracut.
> >
> > Can you try below patch?
> > https://lkml.org/lkml/2013/11/5/88
>
> That seem to have helped, thanks!
>
> Feel free to add:
>
> Tested-by: trenn@suse.de
>
> The problem existed in 3.11 already?
> I had the problem with a 3.11 kernel and tried a
> 3.12 kernel with this patch now.

It's a regression between 3.10 ~ 3.11

>
> It would be great if:
> Cc: stable@vger.kernel.org
> is added as well then.
>

I also like it to be in stable.

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





==============================================================================
TOPIC: module.h: Remove unnecessary semicolon
http://groups.google.com/group/linux.kernel/t/21d44c8ae1bfdf4a?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Nov 7 2013 5:50 pm
From: Joe Perches


On Fri, 2013-11-08 at 11:56 +1030, Rusty Russell wrote:
> Joe Perches <joe@perches.com> writes:
> > On Fri, 2013-11-08 at 09:41 +1030, Rusty Russell wrote:
> >> Joe Perches <joe@perches.com> writes:
> >> > That's a trust issue.
> >> > I've done it. It isn't necessary.
> >>
> >> WTF? Now you just said it's not necessary, I *know* I can't trust you.
> >
> > "It" in this case is the grep that I did
> > prior to sending the patch.
>
> Hi Joe,

Hi Rusty.

> Apologies for my off tone. But I think we got tangled somewhere?
> You said "It isn't necessary".
>
> You maintain that grepping the source to find out if you'd broken
> something "isn't necessary"?
>
> git history shows me you've done lots of these cleanups. I'm pretty
> sure that's not what you meant.

Yeah, I think we did get a little crossed up there.

No, grep and compiling changes are fundamentals
before submitting trivial patches.

What I meant was I had done the grep (and compile
allyesconfig/allmodconfig of the files that use
module_put_and_exit) before sending the patch.

I don't think those are important details for a
commit message.

Dunno if you noticed that I attached the grep results
in my 1st reply.

Sometimes I do put details below the separator
--- line after the signed-off-by.

(I'll also admit I've sent patches without doing
the appropriate checks and screwed them up.
Lessons semi-learned)

> But as maintainer, it's annoying that I had to check myself. I don't
> have personal experience in how diligent you are. If you'd just
> mentioned it, it would have saved me a few minutes and streamlined my
> workflow immensely.
>
> Providing assurance makes me a happy maintainer. So I modified it
> because it sets a clear example for others.
>
> I hope that clarifies,
> Rusty.

No worries. Unfamiliarity also does have its own
set of issues. No problems on my side. Hope you
don't any any this way either.

cheers, Joe

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





==============================================================================
TOPIC: cifs: Use data structures to compute NTLMv2 response offsets
http://groups.google.com/group/linux.kernel/t/acd5fb058fd9bf01?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Nov 7 2013 5:50 pm
From: Jeff Layton


On Thu, 7 Nov 2013 16:40:57 -0700
Tim Gardner <tim.gardner@canonical.com> wrote:

> A bit of cleanup plus some gratuitous variable renaming. I think using
> structures instead of numeric offsets makes this code much more
> understandable.
>
> Also added a comment about current time range expected by
> the server.
>
> Cc: Jeff Layton <jlayton@redhat.com>
> Cc: Steve French <sfrench@samba.org>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> ---
>
> The comment about time of day needing to be within 5 minutes is important (to me
> at least). I spent the best part of a week thinking I had endian issues on powerpc
> when in truth I was just too stupid to notice that the clock
> was not updated. Danged embedded platforms...
>
> checkpatch has some problems with this patch regarding attribute packed, but I chose
> to remain consistent with existing code.
>
> WARNING: __packed is preferred over __attribute__((packed))
> #141: FILE: fs/cifs/cifspdu.h:705:
> + } __attribute__((packed)) challenge;
>
> WARNING: __packed is preferred over __attribute__((packed))
> #142: FILE: fs/cifs/cifspdu.h:706:
> + } __attribute__((packed));
>
> total: 0 errors, 2 warnings, 99 lines checked
>
> Tested on cifs-2.6 for-linus (c481e9feee78c6ce1ba0a1c8c892049f6514f6cf) by mounting
> to iOS 10.8 and Win 8.0 Pro.
>
> rtg
>
> fs/cifs/cifsencrypt.c | 40 ++++++++++++++++++++++++----------------
> fs/cifs/cifspdu.h | 8 +++++++-
> 2 files changed, 31 insertions(+), 17 deletions(-)
>
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index fc6f4f3..4934347 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -548,7 +548,13 @@ static int
> CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
> {
> int rc;
> - unsigned int offset = CIFS_SESS_KEY_SIZE + 8;
> + struct ntlmv2_resp *ntlmv2 = (struct ntlmv2_resp *)
> + (ses->auth_key.response + CIFS_SESS_KEY_SIZE);
> + unsigned int hash_len;
> +
> + /* The MD5 hash starts at challenge_key.key */
> + hash_len = ses->auth_key.len - (CIFS_SESS_KEY_SIZE +
> + offsetof(struct ntlmv2_resp, challenge.key[0]));
>
> if (!ses->server->secmech.sdeschmacmd5) {
> cifs_dbg(VFS, "%s: can't generate ntlmv2 hash\n", __func__);
> @@ -556,7 +562,7 @@ CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
> }
>
> rc = crypto_shash_setkey(ses->server->secmech.hmacmd5,
> - ntlmv2_hash, CIFS_HMAC_MD5_HASH_SIZE);
> + ntlmv2_hash, CIFS_HMAC_MD5_HASH_SIZE);
> if (rc) {
> cifs_dbg(VFS, "%s: Could not set NTLMV2 Hash as a key\n",
> __func__);
> @@ -570,20 +576,21 @@ CalcNTLMv2_response(const struct cifs_ses *ses, char *ntlmv2_hash)
> }
>
> if (ses->server->negflavor == CIFS_NEGFLAVOR_EXTENDED)
> - memcpy(ses->auth_key.response + offset,
> - ses->ntlmssp->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
> + memcpy(ntlmv2->challenge.key,
> + ses->ntlmssp->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
> else
> - memcpy(ses->auth_key.response + offset,
> - ses->server->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
> + memcpy(ntlmv2->challenge.key,
> + ses->server->cryptkey, CIFS_SERVER_CHALLENGE_SIZE);
> rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
> - ses->auth_key.response + offset, ses->auth_key.len - offset);
> + ntlmv2->challenge.key, hash_len);
> if (rc) {
> cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
> return rc;
> }
>
> + /* Note that the MD5 digest over writes anon.challenge_key.key */
> rc = crypto_shash_final(&ses->server->secmech.sdeschmacmd5->shash,
> - ses->auth_key.response + CIFS_SESS_KEY_SIZE);
> + ntlmv2->ntlmv2_hash);
> if (rc)
> cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
>
> @@ -627,7 +634,7 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
> int rc;
> int baselen;
> unsigned int tilen;
> - struct ntlmv2_resp *buf;
> + struct ntlmv2_resp *ntlmv2;
> char ntlmv2_hash[16];
> unsigned char *tiblob = NULL; /* target info blob */
>
> @@ -660,13 +667,14 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
> }
> ses->auth_key.len += baselen;
>
> - buf = (struct ntlmv2_resp *)
> + ntlmv2 = (struct ntlmv2_resp *)
> (ses->auth_key.response + CIFS_SESS_KEY_SIZE);
> - buf->blob_signature = cpu_to_le32(0x00000101);
> - buf->reserved = 0;
> - buf->time = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
> - get_random_bytes(&buf->client_chal, sizeof(buf->client_chal));
> - buf->reserved2 = 0;
> + ntlmv2->blob_signature = cpu_to_le32(0x00000101);
> + ntlmv2->reserved = 0;
> + /* Must be within 5 minutes of the server */
> + ntlmv2->time = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
> + get_random_bytes(&ntlmv2->client_chal, sizeof(ntlmv2->client_chal));
> + ntlmv2->reserved2 = 0;
>
> memcpy(ses->auth_key.response + baselen, tiblob, tilen);
>
> @@ -706,7 +714,7 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
> }
>
> rc = crypto_shash_update(&ses->server->secmech.sdeschmacmd5->shash,
> - ses->auth_key.response + CIFS_SESS_KEY_SIZE,
> + ntlmv2->ntlmv2_hash,
> CIFS_HMAC_MD5_HASH_SIZE);
> if (rc) {
> cifs_dbg(VFS, "%s: Could not update with response\n", __func__);
> diff --git a/fs/cifs/cifspdu.h b/fs/cifs/cifspdu.h
> index 9e5ee34..33df36e 100644
> --- a/fs/cifs/cifspdu.h
> +++ b/fs/cifs/cifspdu.h
> @@ -697,7 +697,13 @@ struct ntlmssp2_name {
> } __attribute__((packed));
>
> struct ntlmv2_resp {
> - char ntlmv2_hash[CIFS_ENCPWD_SIZE];
> + union {
> + char ntlmv2_hash[CIFS_ENCPWD_SIZE];
> + struct {
> + __u8 reserved[8];
> + __u8 key[CIFS_SERVER_CHALLENGE_SIZE];
> + } __attribute__((packed)) challenge;
> + } __attribute__((packed));
> __le32 blob_signature;
> __u32 reserved;
> __le64 time;

(cc'ing Shirish since he wrote most of this code...)

Nice cleanup, I like it.

Acked-by: Jeff Layton <jlayton@redhat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: ARM: pxa/colibri: fix build with CONFIG_USB_OHCI_HCD=y
http://groups.google.com/group/linux.kernel/t/3197e83cdd7d7357?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Nov 7 2013 5:50 pm
From: Marek Vasut


Dear Dmitry Artamonow,

> Fix following build failure observed when support for
> OHCI host controller is enabled.
>
> CC arch/arm/mach-pxa/colibri-evalboard.o
> arch/arm/mach-pxa/colibri-evalboard.c: In function 'colibri_ohci_init':
> arch/arm/mach-pxa/colibri-evalboard.c:68: error: implicit declaration of
> function 'IOMEM' make[1]: *** [arch/arm/mach-pxa/colibri-evalboard.o]
> Error 1
> make: *** [arch/arm/mach-pxa] Error 2
>
> Signed-off-by: Dmitry Artamonow <mad_soft@inbox.lv>

Acked-by: Marek Vasut <marex@denx.de>

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





==============================================================================
TOPIC: PCI: Introduce two new MSI infrastructure calls for masking/unmasking.
http://groups.google.com/group/linux.kernel/t/eba2e16e7822fca1?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Nov 7 2013 5:50 pm
From: Zhenzhong Duan



On 2013-11-07 07:51, Bjorn Helgaas wrote:
> [+cc Thomas, Ingo, Peter, x86 list]
>
> On Wed, Nov 6, 2013 at 2:16 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> Certain platforms do not allow writes in the MSI-X bars
>> to setup or tear down vector values. To combat against
>> the generic code trying to write to that and either silently
>> being ignored or crashing due to the pagetables being marked r/o
>> this patch introduces a platform over-write.
>>
>> Note that we keep two separate, non-weak, functions
>> default_mask_msi_irqs() and default_mask_msix_irqs() for the
>> behavior of the arch_mask_msi_irqs() and arch_mask_msix_irqs(),
>> as the default behavior is needed by x86 PCI code.
>>
>> For Xen, which does not allow the guest to write to MSI-X
>> tables - as the hypervisor is solely responsible for setting
>> the vector values - we implement two nops.
>>
>> CC: Bjorn Helgaas <bhelgaas@google.com>
>> CC: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>> CC: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> I think this is safe, and I'd like to squeeze it into the v3.13 merge
> window next week, since it supersedes three patches Zhenzhong has been
> trying to get in since July [1], and this patch is much simpler to
> understand.
This patch could replace the first two.
I think the third patch of mine is still needed as it does a different
thing.
It optimizes restore path in dom0.

zduan
>
> I *think* this also fixes an actual bug on Xen. Konrad, is there a
> bugzilla or any kind of email problem description that we can include
> here as a reference? I think there's a lost interrupt with qlcnic,
> but I don't know the details or what the failure looks like to a user.
>
> [1] http://lkml.kernel.org/r/51EF44FA.4020903@oracle.com
>
>> ---
>> arch/x86/include/asm/x86_init.h | 3 +++
>> arch/x86/kernel/x86_init.c | 10 ++++++++++
>> arch/x86/pci/xen.c | 13 ++++++++++++-
>> drivers/pci/msi.c | 22 ++++++++++++++++------
>> include/linux/msi.h | 2 ++
>> 5 files changed, 43 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
>> index 828a156..0f1be11 100644
>> --- a/arch/x86/include/asm/x86_init.h
>> +++ b/arch/x86/include/asm/x86_init.h
>> @@ -172,6 +172,7 @@ struct x86_platform_ops {
>>
>> struct pci_dev;
>> struct msi_msg;
>> +struct msi_desc;
>>
>> struct x86_msi_ops {
>> int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
>> @@ -182,6 +183,8 @@ struct x86_msi_ops {
>> void (*teardown_msi_irqs)(struct pci_dev *dev);
>> void (*restore_msi_irqs)(struct pci_dev *dev, int irq);
>> int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
>> + u32 (*msi_mask_irq)(struct msi_desc *desc, u32 mask, u32 flag);
>> + u32 (*msix_mask_irq)(struct msi_desc *desc, u32 flag);
>> };
>>
>> struct IO_APIC_route_entry;
>> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
>> index 8ce0072..021783b 100644
>> --- a/arch/x86/kernel/x86_init.c
>> +++ b/arch/x86/kernel/x86_init.c
>> @@ -116,6 +116,8 @@ struct x86_msi_ops x86_msi = {
>> .teardown_msi_irqs = default_teardown_msi_irqs,
>> .restore_msi_irqs = default_restore_msi_irqs,
>> .setup_hpet_msi = default_setup_hpet_msi,
>> + .msi_mask_irq = default_msi_mask_irq,
>> + .msix_mask_irq = default_msix_mask_irq,
>> };
>>
>> /* MSI arch specific hooks */
>> @@ -138,6 +140,14 @@ void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
>> {
>> x86_msi.restore_msi_irqs(dev, irq);
>> }
>> +u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
>> +{
>> + return x86_msi.msi_mask_irq(desc, mask, flag);
>> +}
>> +u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
>> +{
>> + return x86_msi.msix_mask_irq(desc, flag);
>> +}
>>