* [PATCH] cifs: make CIFS depend on CRYPTO_MD4
From: Jeff Layton @ 2011-01-31 13:41 UTC (permalink / raw)
To: smfrench-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA,
shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w, sjayaraman-l3A5Bk7waGM
In-Reply-To: <4D469C99.9050905-l3A5Bk7waGM@public.gmane.org>
Recently CIFS was changed to use the kernel crypto API for MD4 hashes,
but the Kconfig dependencies were not changed to reflect this.
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Reported-by: Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org>
---
fs/cifs/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
index 27917a5..023d11b 100644
--- a/fs/cifs/Kconfig
+++ b/fs/cifs/Kconfig
@@ -3,6 +3,7 @@ config CIFS
depends on INET
select NLS
select CRYPTO
+ select CRYPTO_MD4
select CRYPTO_MD5
select CRYPTO_HMAC
select CRYPTO_ARC4
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] git-p4: Corrected typo.
From: Vitor Antunes @ 2011-01-31 13:39 UTC (permalink / raw)
To: Thomas Berg; +Cc: git
In-Reply-To: <AANLkTinrALdy9w7K50r=k-oMV9V5+7+LKvui_DSmJ6nK@mail.gmail.com>
Hi Thomas,
On Mon, Jan 31, 2011 at 12:51 PM, Thomas Berg <merlin66b@gmail.com> wrote:
>> Maybe I'm not seeing some obvious limitation, but I can't imagine a
>> branching structure that can't be imported into git. Could please you
>> give me an example?
>
> Here I was thinking of the fact that git-p4 (last time I checked the
> implementation ) uses the list of branch specs in Perforce for
> figuring out the parent of a branch. Our branch specs have changed
> over time (they are used for different integration purposes), so they
> are no longer usable for this purpose.
My personal git-p4 script uses a configuration option to define the
list of branches. I also added an option to get the list of branches
filtered by user (p4 branches -u), which avoids waiting for the server
since I don't have any branches defined.
> I also discovered bugs in git-p4: in some cases, if the first submit
> to a new branch in Perforce is not identical to the branch it derives
> from, the import was not correct.
Another thing that I modified was the following lines:
1559 for (prev, cur) in
zip(self.previousDepotPaths, depotPaths):
1560 for i in range(0, min(len(cur), len(prev))):
1561 if cur[i] <> prev[i]:
1562 i = i - 1
1563 break
This tries to find the root directory of all branches, but does that
comparing char by char. So, if you have something like:
//depot/branches/branch
//depot/branches/branch_test1
//depot/branches/branch_test2
It will assume that your root branch is //depot/branches/branch, which is wrong.
I've modified this to split the string by "/" and compare those items,
making sure it will detect //depot/branches as the root directory.
> One other issue with Perforce, CVS and many other systems is that they
> branch per file. Therefore Perforce can represent partial merges
> between two branches, which git cannot. Because of this, translating
> merges in Perforce to merges in git is not always possible or
> desirable:
> - if you integrate just one file from one branch to another in
> Perforce, and leave the rest unmerged, you probably want to represent
> it as a normal git commit (not a merge)
> - if you merge almost everything, but leave out a file for some
> reason, you may still want to represent it as a merge in git
Yes, merge detection is something that is working. I never tried to
look into this because I don't find it too important for my work flow.
> The git-p4raw tool has excellent handling of merges, see details in
> this file around line 4300:
> https://github.com/samv/git-p4raw/blob/master/git-p4raw
> It supports several algorithms for automatic merge detection, as well
> as manually changing it after the import is done.
I'll have to look into this later :)
Bye,
--
Vitor Antunes
^ permalink raw reply
* Re: Unable to mount CIFS shares
From: Suresh Jayaraman @ 2011-01-31 13:40 UTC (permalink / raw)
To: Shirish Pargaonkar
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA, Steve French, Jeff Layton
In-Reply-To: <AANLkTimZXHzm04htXOPXuUySxzEBofiyP5ZxN=5aqj2m-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/31/2011 07:05 PM, Shirish Pargaonkar wrote:
> On Mon, Jan 31, 2011 at 5:19 AM, Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
>> After updating my tree to HEAD^1, I'm unable to mount CIFS Shares.
>>
>> The topmost commit is:
>>
>> commit d804d41d163c0975d2890c82d7135ada7a2f23a4
>> Author: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Date: Fri Jan 28 15:05:43 2011 -0500
>>
>> cifs: don't pop a printk when sending on a socket is interrupted
>>
>> mount -t cifs //164.99.140.8/share /mnt/cifs/ -o user=vguest
>> Password:
>> mount error(2): No such file or directory
>> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>>
>> Looks like an error caused due to recent crypto changes.
>> Shirish: any clues?
>>
>> dmesg o/p
>> ----------
>>
>> [ 1079.934780] CIFS VFS: mdfour: Crypto md4 allocation error -2
>> [ 1079.934781]
>> [ 1079.934783] CIFS VFS: Error -2 during NTLM authentication
>> [ 1079.934785] CIFS VFS: Send error in SessSetup = -2
>> [ 1079.934802] CIFS VFS: cifs_mount failed w/return code = -2
>>
>> dmesg with cFYI
>> ----------------
>>
>> [ 1121.620509] fs/cifs/cifsfs.c: Devname: //164.99.140.8/share/ flags: 0
>> [ 1121.620637] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 24 with uid: 0
>> [ 1121.620649] fs/cifs/connect.c: Username: vguest
>> [ 1121.623357] fs/cifs/connect.c: UNC: \\164.99.140.8\share ip: 164.99.140.8
>> [ 1121.623382] fs/cifs/connect.c: Socket created
>> [ 1121.623770] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x6d6
>> [ 1121.623804] fs/cifs/fscache.c: CIFS: get client cookie (0xffff88001a202800/0xffff88001ceb6588)
>> [ 1121.623809] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 25 with uid: 0
>> [ 1121.623811] fs/cifs/connect.c: Existing smb sess not found
>> [ 1121.623819] fs/cifs/cifssmb.c: secFlags 0x7
>> [ 1121.623824] fs/cifs/transport.c: For smb_command 114
>> [ 1121.623826] fs/cifs/transport.c: Sending smb: total_len 82
>> [ 1121.623961] fs/cifs/connect.c: Demultiplex PID: 2768
>> [ 1121.625001] fs/cifs/connect.c: rfc1002 length 0x65
>> [ 1121.625007] fs/cifs/misc.c: Calculated size 81 vs length 101 mismatch for mid 1
>> [ 1121.625015] fs/cifs/transport.c: sync_mid_result: cmd=114 mid=1 state=4
>> [ 1121.625018] fs/cifs/cifssmb.c: Dialect: 2
>> [ 1121.625020] fs/cifs/cifssmb.c: negprot rc 0
>> [ 1121.625022] fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x80f3fd TimeAdjust: -19800
>> [ 1121.625024] fs/cifs/sess.c: sess setup type 1
>> [ 1121.627043] CIFS VFS: mdfour: Crypto md4 allocation error -2
>> [ 1121.627044]
>> [ 1121.627046] fs/cifs/smbencrypt.c: SMBNTencrypt Can't generate NT hash, error: -2
>> [ 1121.627048] fs/cifs/cifsencrypt.c: setup_ntlm_response Can't generate NTLM response, error: -2
>> [ 1121.627049] CIFS VFS: Error -2 during NTLM authentication
>> [ 1121.627051] fs/cifs/sess.c: ssetup freeing small buf ffff88001d348140
>> [ 1121.627052] CIFS VFS: Send error in SessSetup = -2
>> [ 1121.627055] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 25) rc = -2
>> [ 1121.627060] fs/cifs/fscache.c: CIFS: release client cookie (0xffff88001a202800/0xffff88001ceb6588)
>> [ 1121.627066] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 24) rc = -2
>> [ 1121.627068] CIFS VFS: cifs_mount failed w/return code = -2
>
> Suresh, looks like plaintext authentication is failing?
> Does the mount succeed with any of sec options such as
> sec=ntlm or sec=ntlmv2 or sec=ntlmssp?
Seems the issue is due to missing MD4 module. After I enabled
CONFIG_CRYPTO_MD4 as suggested by Jeff, the issue went away.
Jeff, would send the fix in a bit.
--
Suresh Jayaraman
^ permalink raw reply
* Re: Tiny version of SE-PostgreSQL got merged
From: Stephen Smalley @ 2011-01-31 13:40 UTC (permalink / raw)
To: cto@itechfrontiers.com; +Cc: KaiGai Kohei, selinux, Eamon Walsh
In-Reply-To: <4D4696F9.90303@itechfrontiers.com>
On Mon, 2011-01-31 at 06:03 -0500, cto@itechfrontiers.com wrote:
> Hello,
>
> It's a great job, but I got a licensing issue: (Due to my job I have to
> scrutinize Legal implications of source codes first)
>
> SE-Postgresql uses libselinux,
>
> libselinux tends to be in Public domain, serving as an interface for
> selinux modules in kernel (which is GPL)
>
> the problem is in libselinux/src/avc.c
>
> http://userspace.selinuxproject.org/trac/browser/libselinux/src/avc.c
>
> the author: Eamon Walsh
> with the National Computer Security Center (the NSA)
> indicated this file is "Derived" from kernel AVC (which is GPL v 2.1)
> _____________________________________________________________
> /*
> * Implementation of the userspace access vector cache (AVC).
> *
> * Author : Eamon Walsh <ewalsh@epoch.ncsc.mil>
> *
> * Derived from the kernel AVC implementation by
> * Stephen Smalley <sds@epoch.ncsc.mil> and
> * James Morris <jmorris@redhat.com>.
> */
> _____________________________________________________________
>
> The term "Derived" has legal implication, any derivative works of GPL
> code should be GPL (the kernel avc is licensed under GPL v 2.1)
>
> To me that file is much like a re-implementation of AVC for libselinux,
> it is obvious for interfacing userspace with kernel module you need to
> follow the structures of what you actually interface with (in this case
> it could be interpreted as original work)
>
> Although due to Legal requirements I have to consider author claims as
> well, and the Author clearly indicated it is a derivative work,
>
> If we consider the author claim then libselinux falls into GPL license
> category anything dynamically or statically linked to it should be
> released under GPL license then, That would make se-postgresql license
> inappropriate which is using postgresql license (actually is a BSD-like
> license and is less restrictive license than GPL).
>
>
>
> Please shed some light on this issue,
libselinux is entirely public domain, with the agreement of all
contributors.
The original kernel AVC code was developed by the NSA and was public
domain by itself, and only fell under the GPL when included as part of
the Linux kernel. There have been some subsequent enhancements to the
kernel AVC, particularly the use of RCU for locking, that are not
present in the libselinux AVC.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* pcm037 warnings
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-01-31 13:36 UTC (permalink / raw)
To: barebox
Hi,
Building arm pcm037_defconfig
Configure: OK
/opt/work/barebox/arch/arm/mach-imx/nand.c:108:2: warning: #warning using empty imx_nand_set_layout(). NAND flash will not work properly if not booting from it
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 1/1] ISI modem version detection with plugin
From: Jessica Nilsson @ 2011-01-31 13:38 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296480736.1520.215.camel@aeonflux>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi Marcel,
On Mon, Jan 31, 2011 at 2:32 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> you do need to split this. At least one for isimodem, one for udev
> changes and one for the u8500 plugin.
Ok,
we will do that.
We thought this was a good logical/functional split that would give
you a good overview.
Do you want them as a 1-3 series patch or should I send each separately?
Best Regards,
Jessica Nilsson
^ permalink raw reply
* [Bug 33077] Broken rendering with black areas in Doom3-demo also falls to 3-4 fps time to time
From: bugzilla-daemon @ 2011-01-31 13:37 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33077-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33077
--- Comment #11 from Tobias Jakobi <liquid.acid@gmx.net> 2011-01-31 05:37:15 PST ---
> The 600g rendering is fixed in mesa master now.
Confirming!
> > > Mesa: User error: GL_INVALID_VALUE in glScissor
>
> I am still getting these.
I haven't checked mesa with debug enabled, but I think we should file a new bug
for that one.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] soc: neo1973_wm8753 audio support does not require scoop
From: Mark Brown @ 2011-01-31 13:36 UTC (permalink / raw)
To: H Hartley Sweeten; +Cc: Linux Kernel, alsa-devel
In-Reply-To: <201101281200.18371.hartleys@visionengravers.com>
On Fri, Jan 28, 2011 at 12:00:18PM -0700, H Hartley Sweeten wrote:
> This driver does not use any of the functionality provided by the scoop
> hardware. Remove the unneeded header.
Applied but please in future remember to:
- Send copies of your patches to the relevant maintainers as documented
in Documentation/SubmittingPatches so maintainers actually see them.
- Make your commit messages match the style for the subsystem you're
submitting to.
This stuff is especially important for minor cleanups like this, please
do try to bear it in mind.
^ permalink raw reply
* mci/stm378x warning
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-01-31 13:34 UTC (permalink / raw)
To: Juergen Beisert; +Cc: barebox
HI,
durring some night build I see this on the drivers/mci/stm378x.c
/opt/work/barebox/drivers/mci/stm378x.c: In function 'mci_request':
/opt/work/barebox/drivers/mci/stm378x.c:354: warning: 'length' may be used uninitialized in this function
/opt/work/barebox/drivers/mci/stm378x.c:354: note: 'length' was declared here
so I guess length will initialized at 0
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH v2] OMAP3630: PM: don't warn the user with a trace in case of PM34XX_ERRATUM
From: Ricardo Salveti de Araujo @ 2011-01-31 13:35 UTC (permalink / raw)
To: linux-omap; +Cc: Ricardo Salveti de Araujo
In case in user has a OMAP3630 < ES1.2 the kernel should warn the user
about the ERRATUM, but using pr_warn instead of WARN_ON is already
enough, as there is nothing else the user can do besides changing the
board.
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
---
v1->v2:
* Use pr_warn instead of printk (Kevin Hilman)
arch/arm/mach-omap2/cpuidle34xx.c | 2 +-
arch/arm/mach-omap2/pm34xx.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index f7b22a1..876eeca 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -464,7 +464,7 @@ void omap_init_power_states(void)
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
omap3_power_states[OMAP3_STATE_C7].valid = 0;
cpuidle_params_table[OMAP3_STATE_C7].valid = 0;
- WARN_ONCE(1, "%s: core off state C7 disabled due to i583\n",
+ pr_warn("%s: core off state C7 disabled due to i583\n",
__func__);
}
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a4aa192..88f09da 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -927,8 +927,7 @@ void omap3_pm_off_mode_enable(int enable)
pwrst->pwrdm == core_pwrdm &&
state == PWRDM_POWER_OFF) {
pwrst->next_state = PWRDM_POWER_RET;
- WARN_ONCE(1,
- "%s: Core OFF disabled due to errata i583\n",
+ pr_warn("%s: Core OFF disabled due to errata i583\n",
__func__);
} else {
pwrst->next_state = state;
--
1.7.2.3
^ permalink raw reply related
* Re: [Qemu-devel] Re: [PATCH v3 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD
From: Stefan Hajnoczi @ 2011-01-31 13:35 UTC (permalink / raw)
To: Jan Kiszka
Cc: Marcelo Tosatti, Stefan Hajnoczi, Avi Kivity, kvm@vger.kernel.org,
qemu-devel@nongnu.org
In-Reply-To: <4D46A884.5060906@siemens.com>
On Mon, Jan 31, 2011 at 12:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2011-01-31 13:13, Stefan Hajnoczi wrote:
>> On Mon, Jan 31, 2011 at 11:27 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2011-01-31 11:03, Avi Kivity wrote:
>>>> On 01/27/2011 04:33 PM, Jan Kiszka wrote:
>>>>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
>>>>> checking for exit_request on vcpu entry and timer signals arriving
>>>>> before KVM starts to catch them. Plug it by blocking both timer related
>>>>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
>>>>>
>>>>> As this fix depends on real signalfd support (otherwise the timer
>>>>> signals only kick the compat helper thread, and the main thread hangs),
>>>>> we need to detect the invalid constellation and abort configure.
>>>>>
>>>>> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
>>>>> CC: Stefan Hajnoczi<stefanha@linux.vnet.ibm.com>
>>>>> ---
>>>>>
>>>>> I don't want to invest that much into !IOTHREAD anymore, so let's see if
>>>>> the proposed catch&abort is acceptable.
>>>>>
>>>>
>>>> I don't understand the dependency on signalfd. The normal way of doing
>>>> things, either waiting for the signal in sigtimedwait() or in
>>>> ioctl(KVM_RUN), works with SIGALRM just fine.
>>>
>>> And how would you be kicked out of the select() call if it is waiting
>>> with a timeout? We only have a single thread here.
>>>
>>> The only alternative is Stefan's original proposal. But that required
>>> fiddling with the signal mask twice per KVM_RUN.
>>
>> I think my original patch messed with the sigmask in the wrong place,
>> as you mentioned doing it twice per KVM_RUN isn't a good idea. I
>> wonder if we can enable SIGALRM only in blocking calls and guest code
>> execution but without signalfd. It might be possible, I don't see an
>> immediate problem with doing that, we might have to use pselect(2) or
>> similar in a few places.
>
> My main concern about alternative approaches is that IOTHREAD is about
> to become the default, and hardly anyone (of the few upstream KVM users)
> will run without it in the foreseeable future. The next step will be the
> removal of any !CONFIG_IOTHREAD section. So, how much do we want to
> invest here (provided my proposal has not remaining issues)?
Yes, you're right. I'm not volunteering to dig more into this, the
best case would be to switch to a non-I/O thread world that works for
everybody.
Stefan
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v3 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD
From: Stefan Hajnoczi @ 2011-01-31 13:35 UTC (permalink / raw)
To: Jan Kiszka
Cc: Avi Kivity, Marcelo Tosatti, qemu-devel@nongnu.org,
kvm@vger.kernel.org, Stefan Hajnoczi
In-Reply-To: <4D46A884.5060906@siemens.com>
On Mon, Jan 31, 2011 at 12:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2011-01-31 13:13, Stefan Hajnoczi wrote:
>> On Mon, Jan 31, 2011 at 11:27 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2011-01-31 11:03, Avi Kivity wrote:
>>>> On 01/27/2011 04:33 PM, Jan Kiszka wrote:
>>>>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
>>>>> checking for exit_request on vcpu entry and timer signals arriving
>>>>> before KVM starts to catch them. Plug it by blocking both timer related
>>>>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
>>>>>
>>>>> As this fix depends on real signalfd support (otherwise the timer
>>>>> signals only kick the compat helper thread, and the main thread hangs),
>>>>> we need to detect the invalid constellation and abort configure.
>>>>>
>>>>> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
>>>>> CC: Stefan Hajnoczi<stefanha@linux.vnet.ibm.com>
>>>>> ---
>>>>>
>>>>> I don't want to invest that much into !IOTHREAD anymore, so let's see if
>>>>> the proposed catch&abort is acceptable.
>>>>>
>>>>
>>>> I don't understand the dependency on signalfd. The normal way of doing
>>>> things, either waiting for the signal in sigtimedwait() or in
>>>> ioctl(KVM_RUN), works with SIGALRM just fine.
>>>
>>> And how would you be kicked out of the select() call if it is waiting
>>> with a timeout? We only have a single thread here.
>>>
>>> The only alternative is Stefan's original proposal. But that required
>>> fiddling with the signal mask twice per KVM_RUN.
>>
>> I think my original patch messed with the sigmask in the wrong place,
>> as you mentioned doing it twice per KVM_RUN isn't a good idea. I
>> wonder if we can enable SIGALRM only in blocking calls and guest code
>> execution but without signalfd. It might be possible, I don't see an
>> immediate problem with doing that, we might have to use pselect(2) or
>> similar in a few places.
>
> My main concern about alternative approaches is that IOTHREAD is about
> to become the default, and hardly anyone (of the few upstream KVM users)
> will run without it in the foreseeable future. The next step will be the
> removal of any !CONFIG_IOTHREAD section. So, how much do we want to
> invest here (provided my proposal has not remaining issues)?
Yes, you're right. I'm not volunteering to dig more into this, the
best case would be to switch to a non-I/O thread world that works for
everybody.
Stefan
^ permalink raw reply
* Re: Unable to mount CIFS shares
From: Shirish Pargaonkar @ 2011-01-31 13:35 UTC (permalink / raw)
To: Suresh Jayaraman; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA, Steve French
In-Reply-To: <4D469AA6.7060401-l3A5Bk7waGM@public.gmane.org>
On Mon, Jan 31, 2011 at 5:19 AM, Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
> After updating my tree to HEAD^1, I'm unable to mount CIFS Shares.
>
> The topmost commit is:
>
> commit d804d41d163c0975d2890c82d7135ada7a2f23a4
> Author: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Fri Jan 28 15:05:43 2011 -0500
>
> cifs: don't pop a printk when sending on a socket is interrupted
>
> mount -t cifs //164.99.140.8/share /mnt/cifs/ -o user=vguest
> Password:
> mount error(2): No such file or directory
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
>
> Looks like an error caused due to recent crypto changes.
> Shirish: any clues?
>
> dmesg o/p
> ----------
>
> [ 1079.934780] CIFS VFS: mdfour: Crypto md4 allocation error -2
> [ 1079.934781]
> [ 1079.934783] CIFS VFS: Error -2 during NTLM authentication
> [ 1079.934785] CIFS VFS: Send error in SessSetup = -2
> [ 1079.934802] CIFS VFS: cifs_mount failed w/return code = -2
>
> dmesg with cFYI
> ----------------
>
> [ 1121.620509] fs/cifs/cifsfs.c: Devname: //164.99.140.8/share/ flags: 0
> [ 1121.620637] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 24 with uid: 0
> [ 1121.620649] fs/cifs/connect.c: Username: vguest
> [ 1121.623357] fs/cifs/connect.c: UNC: \\164.99.140.8\share ip: 164.99.140.8
> [ 1121.623382] fs/cifs/connect.c: Socket created
> [ 1121.623770] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x6d6
> [ 1121.623804] fs/cifs/fscache.c: CIFS: get client cookie (0xffff88001a202800/0xffff88001ceb6588)
> [ 1121.623809] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 25 with uid: 0
> [ 1121.623811] fs/cifs/connect.c: Existing smb sess not found
> [ 1121.623819] fs/cifs/cifssmb.c: secFlags 0x7
> [ 1121.623824] fs/cifs/transport.c: For smb_command 114
> [ 1121.623826] fs/cifs/transport.c: Sending smb: total_len 82
> [ 1121.623961] fs/cifs/connect.c: Demultiplex PID: 2768
> [ 1121.625001] fs/cifs/connect.c: rfc1002 length 0x65
> [ 1121.625007] fs/cifs/misc.c: Calculated size 81 vs length 101 mismatch for mid 1
> [ 1121.625015] fs/cifs/transport.c: sync_mid_result: cmd=114 mid=1 state=4
> [ 1121.625018] fs/cifs/cifssmb.c: Dialect: 2
> [ 1121.625020] fs/cifs/cifssmb.c: negprot rc 0
> [ 1121.625022] fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x80f3fd TimeAdjust: -19800
> [ 1121.625024] fs/cifs/sess.c: sess setup type 1
> [ 1121.627043] CIFS VFS: mdfour: Crypto md4 allocation error -2
> [ 1121.627044]
> [ 1121.627046] fs/cifs/smbencrypt.c: SMBNTencrypt Can't generate NT hash, error: -2
> [ 1121.627048] fs/cifs/cifsencrypt.c: setup_ntlm_response Can't generate NTLM response, error: -2
> [ 1121.627049] CIFS VFS: Error -2 during NTLM authentication
> [ 1121.627051] fs/cifs/sess.c: ssetup freeing small buf ffff88001d348140
> [ 1121.627052] CIFS VFS: Send error in SessSetup = -2
> [ 1121.627055] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 25) rc = -2
> [ 1121.627060] fs/cifs/fscache.c: CIFS: release client cookie (0xffff88001a202800/0xffff88001ceb6588)
> [ 1121.627066] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 24) rc = -2
> [ 1121.627068] CIFS VFS: cifs_mount failed w/return code = -2
>
>
> --
> Suresh Jayaraman
>
Suresh, looks like plaintext authentication is failing?
Does the mount succeed with any of sec options such as
sec=ntlm or sec=ntlmv2 or sec=ntlmssp?
^ permalink raw reply
* Re: [RFC PATCH 2/2] power_supply: Add new LED trigger charging-blink-solid-full
From: Anton Vorontsov @ 2011-01-31 13:33 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: linux-kernel, Richard Purdie, Arnaud Patard (Rtp), Andrew Morton
In-Reply-To: <1294417697-4692-3-git-send-email-anarsoul@gmail.com>
On Fri, Jan 07, 2011 at 06:28:17PM +0200, Vasily Khoruzhick wrote:
> Add new trigger to power_supply LEDs. It will blink when
> battery is charging, and stay solid when battery is charged.
> It's usefull to indicate battery state when there's only one
> LED available.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
Appled both patches to battery-2.6.git, thanks!
> drivers/power/power_supply_leds.c | 18 ++++++++++++++++++
> include/linux/power_supply.h | 2 ++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/power/power_supply_leds.c b/drivers/power/power_supply_leds.c
> index 031a554..b640bbf 100644
> --- a/drivers/power/power_supply_leds.c
> +++ b/drivers/power/power_supply_leds.c
> @@ -21,6 +21,7 @@
> static void power_supply_update_bat_leds(struct power_supply *psy)
> {
> union power_supply_propval status;
> + unsigned long delay_on = 0, delay_off = 0;
Changed this to
unsigned long delay_on = 0;
unsigned long delay_off = 0;
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: [PATCH 2/4] pidns: Call pid_ns_prepare_proc from create_pid_namespace
From: Daniel Lezcano @ 2011-01-31 13:33 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: akpm, ebiederm, containers, linux-kernel, clg
In-Reply-To: <20110131132207.GA26995@redhat.com>
On 01/31/2011 02:22 PM, Oleg Nesterov wrote:
> On 01/31, Daniel Lezcano wrote:
>> @@ -96,6 +97,9 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
>> for (i = 1; i< PIDMAP_ENTRIES; i++)
>> atomic_set(&ns->pidmap[i].nr_free, BITS_PER_PAGE);
>>
>> + if (pid_ns_prepare_proc(ns))
>> + goto out_free_map;
>> +
>> return ns;
> This is not right, afaics. I already sent the similar patches, but
> they were ignored ;)
>
> Please see http://marc.info/?l=linux-kernel&m=127697484000334
>
> If pid_ns_prepare_proc() fails we shouldn't blindly return ENOMEM
> and, more importantly, we need put_pid_ns(parent_ns).
Oh, ok. Right. Thanks for the pointer.
Are you ok if I replace the patch 2/4 with your patch ?
^ permalink raw reply
* Re: [PATCH 2/4] pidns: Call pid_ns_prepare_proc from create_pid_namespace
From: Daniel Lezcano @ 2011-01-31 13:33 UTC (permalink / raw)
To: Oleg Nesterov
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, clg-NmTC/0ZBporQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110131132207.GA26995-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 01/31/2011 02:22 PM, Oleg Nesterov wrote:
> On 01/31, Daniel Lezcano wrote:
>> @@ -96,6 +97,9 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
>> for (i = 1; i< PIDMAP_ENTRIES; i++)
>> atomic_set(&ns->pidmap[i].nr_free, BITS_PER_PAGE);
>>
>> + if (pid_ns_prepare_proc(ns))
>> + goto out_free_map;
>> +
>> return ns;
> This is not right, afaics. I already sent the similar patches, but
> they were ignored ;)
>
> Please see http://marc.info/?l=linux-kernel&m=127697484000334
>
> If pid_ns_prepare_proc() fails we shouldn't blindly return ENOMEM
> and, more importantly, we need put_pid_ns(parent_ns).
Oh, ok. Right. Thanks for the pointer.
Are you ok if I replace the patch 2/4 with your patch ?
^ permalink raw reply
* storing the messages at events
From: mohit verma @ 2011-01-31 13:33 UTC (permalink / raw)
To: kernelnewbies
hi ,
my module produces some data (very cititcal) and that i want to log that to
some disk residing file like log files. So among several ways like using
syslog (and family) ,audit daemon i am not finding the way to use the
functionalities of any of these subsystems .i mean : practically i am still
unable to do that.
can someone point me to some practical implementations used by some other
modules or some practically sound articles to achieve this?
thanks a lot in advance.
--
........................
*MOHIT VERMA*
--
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110131/e1c8a500/attachment.html
^ permalink raw reply
* Re: [PATCH 1/1] ISI modem version detection with plugin
From: Marcel Holtmann @ 2011-01-31 13:32 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296479491-29491-1-git-send-email-jessica.j.nilsson@stericsson.com>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
Hi Jessica,
> Makefile.am | 4 +
> drivers/isimodem/debug.c | 39 ++++
> drivers/isimodem/debug.h | 4 +
> drivers/isimodem/mtc.h | 38 ++++
> drivers/isimodem/version.h | 26 +++
> plugins/ofono.rules | 3 +
> plugins/u8500.c | 477 ++++++++++++++++++++++++++++++++++++++++++++
> plugins/udev.c | 5 +-
> 8 files changed, 595 insertions(+), 1 deletions(-)
> create mode 100644 drivers/isimodem/version.h
> create mode 100644 plugins/u8500.c
you do need to split this. At least one for isimodem, one for udev
changes and one for the u8500 plugin.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 7/7] zram/xvmalloc: combine duplicate block delete code
From: Nitin Gupta @ 2011-01-31 13:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, Pekka Enberg, devel, linux-kernel
In-Reply-To: <20110128150155.GH2062@linux.vnet.ibm.com>
On 01/28/2011 10:01 AM, Robert Jennings wrote:
> This patch eliminates duplicate code. The remove_block_head function
> is a special case of remove_block which can be contained in remove_block
> without confusion.
>
> The portion of code in remove_block_head which was noted as "DEBUG ONLY"
> is now mandatory. Doing this provides consistent management of the double
> linked list of blocks under a freelist and makes this consolidation
> of delete block code safe. The first and last blocks will have NULL
> pointers in their previous and next page pointers respectively.
>
> Additionally, any time a block is removed from a free list the next and
> previous pointers will be set to NULL to avoid misuse outside xvmalloc.
>
> Signed-off-by: Robert Jennings<rcj@linux.vnet.ibm.com>
The reason for introducing remove_block_head() as a separate function
was to make malloc slightly faster but since I lack any profiling data,
I'm not very sure if this may impact performance. Ideally, some sort of
data with some malloc heavy test would have been useful. Anyways, I
think major allocator changes will happen when we make xvmalloc
allocated memory reclaimable, so maybe we can defer profiling.
Acked-by: Nitin Gupta <ngupta@vflare.org>
Thanks,
Nitin
^ permalink raw reply
* [U-Boot] Query: Which u-boot version supports PPC476FP?
From: prakash bedge @ 2011-01-31 13:31 UTC (permalink / raw)
To: u-boot
Hi All,
Could anyone tell which version of u-boot supports PPC476FP processor?
Thanks & Regards,
Prakash Bedge
^ permalink raw reply
* Re: [PATCH 2/4] pidns: Call pid_ns_prepare_proc from create_pid_namespace
From: Oleg Nesterov @ 2011-01-31 13:22 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: akpm, ebiederm, containers, linux-kernel, clg
In-Reply-To: <1296469525-30111-3-git-send-email-daniel.lezcano@free.fr>
On 01/31, Daniel Lezcano wrote:
>
> @@ -96,6 +97,9 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
> for (i = 1; i < PIDMAP_ENTRIES; i++)
> atomic_set(&ns->pidmap[i].nr_free, BITS_PER_PAGE);
>
> + if (pid_ns_prepare_proc(ns))
> + goto out_free_map;
> +
> return ns;
This is not right, afaics. I already sent the similar patches, but
they were ignored ;)
Please see http://marc.info/?l=linux-kernel&m=127697484000334
If pid_ns_prepare_proc() fails we shouldn't blindly return ENOMEM
and, more importantly, we need put_pid_ns(parent_ns).
Oleg.
^ permalink raw reply
* Re: [ANNOUNCE] undertaker 1.0
From: Christian Dietrich @ 2011-01-31 13:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Reinhard Tartler, Linux Kernel Mailing List, vamos, Julia Lawall
In-Reply-To: <alpine.LFD.2.00.1101282126210.31804@localhost6.localdomain6>
Thomas Gleixner <tglx@linutronix.de> writes:
> The one in manage.c is not:
>
> 921 #ifdef CONFIG_IRQ_RELEASE_METHOD
>
> CONFIG_IRQ_RELEASE_METHOD is set by arch/um. Ditto for include/linux/irq.h
This problem was the result of an implementation bug. We didn't create a
feature model for um. This is now fixed in our master branch and will be
in the next minor release.
> It'd be nice if the web interface would have a knob to jump to the
> next red section. Scrolling through is annoying.
I generated a new code browser for -rc2[1]. There you can press 'n' to jump
to the next defect. I've only tested the javascript code with chromium,
but it should work anywhere else too.
[1] http://www4.informatik.uni-erlangen.de/Research/VAMOS/linux-trees/v2.6.38-rc2/
--
(λ x . x x) (λ x . x x) -- See how beautiful the lambda is
No documentation is better than bad documentation
^ permalink raw reply
* Re: [PATCH] atmodem: implement standard PIN retries
From: Marcel Holtmann @ 2011-01-31 13:30 UTC (permalink / raw)
To: ofono
In-Reply-To: <201101311522.05246.remi.denis-courmont@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
Hi Remi,
> > > drivers/atmodem/sim.c | 48
> > > ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 48
> > > insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
> > > index 0938998..dfd40f8 100644
> > > --- a/drivers/atmodem/sim.c
> > > +++ b/drivers/atmodem/sim.c
> > > @@ -57,6 +57,7 @@ static const char *cpin_prefix[] = { "+CPIN:", NULL };
> > >
> > > static const char *clck_prefix[] = { "+CLCK:", NULL };
> > > static const char *huawei_cpin_prefix[] = { "^CPIN:", NULL };
> > > static const char *xpincnt_prefix[] = { "+XPINCNT:", NULL };
> > >
> > > +static const char *cpinr_prefixes[] = { "+CPINR:", "+CPINRE:", NULL };
> >
> > if you are not processing +CPINRE, why bother consuming it in the first
> > place?
>
> So that they're not misinterpreted as unsolicited responses.
they would be. Do you care?
> > > static const char *none_prefix[] = { NULL };
> > >
> > > static void at_crsm_info_cb(gboolean ok, GAtResult *result, gpointer
> > > user_data)
> > >
>
> > > @@ -577,6 +622,9 @@ static void at_pin_retries_query(struct ofono_sim
> > > *sim,
> > >
> > > break;
> > >
> > > default:
> > > + if (g_at_chat_send(sd->chat, "AT+CPINR", cpinr_prefixes,
> > > + at_cpinr_cb, cbd, g_free) > 0)
> > > + return;
> >
> > since this command is pretty new, don't we need to check if it is
> > supported? Is there any impact not checking it?
>
> This will just defer the (failure) callback until the ERROR response.
Okay. If there is no impact here I am fine with it.
Regards
Marcel
^ permalink raw reply
* Re: Question about your DSP topic branch
From: Mark Brown @ 2011-01-31 13:30 UTC (permalink / raw)
To: Patrick Lai; +Cc: alsa-devel
In-Reply-To: <4D41E8FE.4070206@codeaurora.org>
On Thu, Jan 27, 2011 at 01:51:58PM -0800, Patrick Lai wrote:
> On 1/26/2011 3:20 AM, Mark Brown wrote:
> >Yup, but it's not really a big cost - they're all so trivial.
> Currently, I already have few dummy codec drivers in mind for the
> project I am working on. I am not worried about the size of these
> files. Beside having tons of dummy codec drivers in the source tree,
> I am also looking at the value and effort to upstream these trivial
> drivers.
Like I say, it's utterly trivial.
^ permalink raw reply
* Hello, first mail and a quesion.
From: Matías Goinheix Freitas @ 2011-01-31 13:30 UTC (permalink / raw)
To: alsa-devel
Hello people,
This is my first mail here. Before purchasing the cheap awful USB interface
I have now, I was in love with the Saffire 6 USB. Sadly it didn't run on
linux. A friend of mine got it (he uses another OS) and so I tested for
myself that it's not recognized by Ubuntu 10.04.
My question is this: I have access to that interface because I can borrow it
anytime I want. I don't have the slightest idea on developing a driver or
hacking stuff (I suscribed to this mailing list because I thought it's the
one I could have contact with developers even though I'm not, if I'm in the
wrong place I will unsuscribe it's not my intention to bother). Is there any
way I could help developers interested in creating a driver for this
interfase? I don't know if that makes sense, but maybe there's a project
going on that I'm unaware of and they could use some info about that
interface. I could copy/paste/send them the info they needed, or run the
commands they tell me to run and give them the info.
Thank you,
Matías
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.