am kara wrote:
> hello,
>
> If kernel does kmap_atomic(temporary kernel mapping)
> on behalf of a process by a cpu, does the process will
> continue to run and no other process can be scheduled
> to switch it off?(till kunmap_atomic is done)
Effectively, kmap_atomic implementations call pagefault
I saw this too with checkpatch.pl version 0.12
It seems like checkpatch.pl knows only about types derived
from @typeList by build_types.
Example below...
Benny
$ cat < wrote:
> On Sun, Feb 10, 2008 at 03:33:02PM +0100, Marcin Slusarz wrote:
>> Hi
>>
>> Checkpatch in current mainline outputs foll
Seriously, can't you just add a disclaimer to the README file?
In http://lkml.org/lkml/2008/2/9/29, Luben Tuikov made an interesting
point that in many cases "illegal" refers to a valid value that violates
the specification, so the term "invalid" may be technically incorrect.
Benny
On Feb. 11, 2
On Feb. 11, 2008, 18:40 +0200, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 11, 2008 at 06:05:48PM +0200, Benny Halevy wrote:
>> I saw this too with checkpatch.pl version 0.12
>> It seems like checkpatch.pl knows only about types derived
>> from @typeList by
On Feb. 11, 2008, 20:42 +0200, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 11, 2008 at 06:58:08PM +0200, Benny Halevy wrote:
>> OK, but the return type doesn't have to be in the patched line, it could be
>> in
>> a synchronization line or even missing
On Feb. 12, 2008, 20:36 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Tue, 12 Feb 2008, Benny Halevy wrote:
>> IMHO, this base tree should typically be based off of linus' tree
>> and kept rebased on top of it. This way you get the mainline fixes
>>
On Feb. 12, 2008, 19:41 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 09:09 -0800, Linus Torvalds wrote:
>> (a) create a base tree with _just_ that fundamental infrastructure change,
>> and make sure that base branch is so obviously good that there is no
>> q
On Feb. 12, 2008, 18:36 +0200, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> David Miller wrote:
>> This is why, with the networking, we've just tossed all of the network
>> driver stuff in there too. I can rebase freely, remove changesets,
>> rework them, etc. and this causes a very low amount of pain
On Feb. 12, 2008, 17:07 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-02-11 at 21:53 -0800, Greg KH wrote:
>>> this is why you need specific trees for just the API change, and these
>>> need to EXPLICITLY go first before EVERYTHING ELSE. Yes this needs a
>>> bit of coordination,
On Feb. 13, 2008, 19:52 +0200, "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
>> So just the fact that the right commit gets blamed when somebody does a
>> "git bisect" is I think a big issue. It's just fundamentally more fair to
>>
On Feb. 14, 2008, 20:29 +0200, "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 5:35 AM, Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I have created the first cut of the linux-next tree at
>> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
>>
>>
Update my email address to new company name.
Cc: Boaz Harrosh
Signed-off-by: Benny Halevy
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 229c66b..0a754ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6125,7 +6125,7 @@ F
Was version 0.13 NACKed?
Benny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Feb. 06, 2008, 16:43 +0200, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 05, 2008 at 09:26:47PM +0200, Benny Halevy wrote:
>> Was version 0.13 NACKed?
>
> It was picked up by Andrew for -mm according to my email. I do not
> think there has been an -mm re
On Feb. 06, 2008, 14:16 +0200, "Bart Van Assche" <[EMAIL PROTECTED]> wrote:
> On Feb 5, 2008 6:01 PM, Erez Zilber <[EMAIL PROTECTED]> wrote:
>> Using such large values for FirstBurstLength will give you poor
>> performance numbers for WRITE commands (with iSER). FirstBurstLength
>> means how much d
On Feb. 23, 2008, 5:38 -0800, "Paolo Ciarrocchi" <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 4:13 PM, Paolo Ciarrocchi
> <[EMAIL PROTECTED]> wrote:
>> On Jan 28, 2008 3:56 PM, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>> > On Mon, Jan 14, 2008 at 11:29:13PM +0100, Paolo Ciarrocchi wrote:
On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <[EMAIL PROTECTED]> wrote:
> Krzysztof Halasa wrote:
>> Richard Knutsson <[EMAIL PROTECTED]> writes:
>>
>>
>>> Why hinder a developer who prefer
>>> 2, 4, 6 or any other != 8 width?
>>>
>> I guess we could use tabs only at the line start, for i
On Feb. 24, 2008, 19:29 -0800, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 24, 2008 at 07:14:13PM +0100, Paolo Ciarrocchi wrote:
>> On Sun, Feb 24, 2008 at 4:18 PM, Benny Halevy <[EMAIL PROTECTED]> wrote:
>> [...]
>>> How about:
>>> -
On Feb. 25, 2008, 13:40 -0800, Richard Knutsson <[EMAIL PROTECTED]> wrote:
> Benny Halevy wrote:
>> On Feb. 24, 2008, 7:40 -0800, Richard Knutsson <[EMAIL PROTECTED]> wrote:
>>
>>> Krzysztof Halasa wrote:
>>>
>
Pete, the subject says "PATCH 1/2" but I didn't see any follow-up message
for PATCH 2/2. Just wondering :)
Benny
On Feb. 26, 2008, 10:27 -0800, Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38.
>
> The original commit breaks iSER reliably, ma
Diabolical ;-)
Thanks for the pointer!
Benny
On Feb. 26, 2008, 11:39 -0800, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote:
>> Pete, the subject says "PATCH 1/2" but I didn't see any follow-up message
&g
On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
wrote:
> Em Thu, Jan 03, 2008 at 12:26:10PM +, Christoph Hellwig escreveu:
>> On Thu, Jan 03, 2008 at 11:10:58AM +, Andy Whitcroft wrote:
>>> We have had some stabs at changing this, but no consensus was reached on
On Jan. 18, 2008, 13:37 +0200, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 17, 2008 at 11:19:23AM -0800, Andrew Morton wrote:
>> On Thu, 17 Jan 2008 16:23:51 - Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>
>>> This version brings a large number of fixes which have built up over
>>> t
void *p[1] = {
#if defined(X)
&x
#elif defined(Y)
&y
#else
&z
#endif
};
}
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
---
scripts/checkpatch.pl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a
On Nov. 29, 2007, 3:19 +0200, "Ming Lei" <[EMAIL PROTECTED]> wrote:
> 2007/11/29, Jan Engelhardt <[EMAIL PROTECTED]>:
>> On Nov 29 2007 01:05, J.A. Magallón wrote:
>>> Since begin of the ages the build of the nvidia driver says things like
>>> this:
>>>
>> Explicitly adding -Wpointer-arith to ones
On Jan. 14, 2008, 17:48 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> This error:
>
> ERROR: no space before that close parenthesis ')'
> #501: FILE: drivers/scsi/dpt_i2o.c:2299:
> + if (dev_status == 0x02 /*CHECK_CONDITION*/) {
>
> Is definitely wrong. I think it's stripped
On Nov. 10, 2007, 14:27 +0200, Xavier Bestel <[EMAIL PROTECTED]> wrote:
> Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
>> Hi Benny :)
>>
>> * Benny Halevy <[EMAIL PROTECTED]> dixit:
>>> I would like to hear peoples opinion about the inden
On Nov. 11, 2007, 11:23 +0200, James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
> DervishD wrote:
>> Bonjour Xavier :)
>>
>> * Xavier Bestel <[EMAIL PROTECTED]> dixit:
>>
>>> Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
On Nov. 08, 2007, 17:58 +0200, Chris Snook <[EMAIL PROTECTED]> wrote:
> Benny Halevy wrote:
>> Greetings,
>>
>> I would like to hear peoples opinion about the indentation convention
>> described below that I personally found the most practical with
>> sever
Dave, this sounds like a good idea.
How about cross posting this message also to [EMAIL PROTECTED]
Benny
On Nov. 12, 2007, 10:16 +0200, David Miller <[EMAIL PROTECTED]> wrote:
> Because the sourceforge lists are a huge collection of spam and
> subscriber-posting only, and someone reminded me of t
I wonder if this is a similar hang to what Christian was seeing here:
http://lkml.org/lkml/2007/11/13/319
Benny
On Nov. 14, 2007, 9:04 +0200, Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
> see a hang when accessing some NFS expor
It looks like it could be nice to define and use a helper for
page_address(sg_page(sg)) (although 11 call sites could use it
after this patch)
#define sg_pgaddr(sg) page_address(sg_page(sg))
Note that mips sg_{un,}map_sg checked for page_address(sg->page) != 0
before calling __dma_sync(addr + sg-
On Oct. 22, 2007, 22:16 +0200, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Oct 2007 12:49:40 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>>
>> On Mon, 22 Oct 2007, Geert Uytterhoeven wrote:
>>> Better safe than sorry...
>>>
>>> Is it possible that a chain entry pointer has bit 1
On Oct. 24, 2007, 10:32 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24 2007, FUJITA Tomonori wrote:
>> On Tue, 23 Oct 2007 20:49:40 +0530
>> Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> Kernel oops is triggered while running fsx-linux test, followed by cpu
>>> soft
On Oct. 24, 2007, 10:50 +0200, Benny Halevy <[EMAIL PROTECTED]> wrote:
> On Oct. 24, 2007, 10:32 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
>> On Wed, Oct 24 2007, FUJITA Tomonori wrote:
>>> On Tue, 23 Oct 2007 20:49:40 +0530
>>> Kamalesh Babulal
On Oct. 25, 2007, 17:40 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Thu, 25 Oct 2007, Rusty Russell wrote:
>> On Wednesday 24 October 2007 01:22:55 Linus Torvalds wrote:
>>> Well, I'd personally actually prefer to *not* have the count be passed
>>> down explicitly, because it's just to
On Oct. 17, 2007, 20:22 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 17 2007, Linus Torvalds wrote:
>>
>> On Wed, 17 Oct 2007, Jens Axboe wrote:
So avoiding the "sg_next()" on the last entry is pointless.
>>> Yeah, I didn't quite understand why if sg was valid, why dereferencing
On Oct. 18, 2007, 14:15 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> /**
> * sg_next - return the next scatterlist entry in a list
> @@ -43,10 +51,15 @@ static inline void sg_init_one(struct scatterlist *sg,
> const void *buf,
> */
> static inline struct scatterlist *sg_next(struct scatte
On Oct. 18, 2007, 15:32 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> static inline struct scatterlist *sg_next(struct scatterlist *sg)
> {
> - sg++;
> -
> - if (unlikely(sg_is_chain(sg)))
> +#ifdef CONFIG_DEBUG_SG
> + BUG_ON(sg->sg_magic != SG_MAGIC);
> +#endif
> + if (sg_is_las
On Oct. 18, 2007, 16:05 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 18 2007, Jens Axboe wrote:
>> On Thu, Oct 18 2007, Benny Halevy wrote:
>>>>return sg;
>>>> }
>>>> @@ -83,6 +96,9 @@ static inline struct scatterlist *sg_last
On Nov. 06, 2007, 7:06 +0200, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 03 Nov 2007 07:09:25 -0400 Steve Dickson <[EMAIL PROTECTED]> wrote:
>
>> The following patch stops NFS sillyname renames and umounts from racing.
>
> (appropriate cc's added)
>
>> I have a test script does the follo
Greetings,
I would like to hear peoples opinion about the indentation convention
described below that I personally found the most practical with
several different editors.
The gist of it is that tabs should be used for nesting, not for decoration.
Indent your code with as many tabs as your nestin
Douglas Gilbert wrote:
> Boaz Harrosh wrote:
>> - Introduce a new enum dma_data_direction data_dir member in struct request.
>> and remove the RW bit from request->cmd_flag
>> - Add new API to query request direction.
>> - Adjust existing API and implementation.
>> - Cleanup wrong use of DMA_BIDI
James Bottomley wrote:
> On Mon, 2007-01-22 at 01:25 +0200, Boaz Harrosh wrote:
>> - Instantiate another request_io_part in request for bidi_read.
>> - Define & Implement new API for accessing bidi parts.
>> - API to Build bidi requests and map to sglists.
>> - Define new end_that_request_block() f
Muli Ben-Yehuda wrote:
> On Mon, Jan 22, 2007 at 01:21:28AM +0200, Boaz Harrosh wrote:
>
>> - Introduce a new enum dma_data_direction data_dir member in struct request.
>> and remove the RW bit from request->cmd_flag
>
> Some architecture use 'enum dma_data_direction' and some 'int
> dma_data_d
Douglas Gilbert wrote:
> Benny Halevy wrote:
>> Douglas Gilbert wrote:
>
> Perhaps the right use of DMA_BIRECTIONAL needs to be
> defined.
>
> Could it be used with a XDWRITE(10) SCSI command
> defined in sbc3r07.pdf at http://www.t10.org ? I suspect
> using two s
Muli Ben-Yehuda wrote:
> On Tue, Jan 23, 2007 at 03:45:00PM +0200, Benny Halevy wrote:
>
>>>> +static inline int dma_uni_dir(enum dma_data_direction dir)
>>>> +{
>>>> + return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
>>>> +
Mikulas Patocka wrote:
>>> If user (or script) doesn't specify that flag, it doesn't help. I think
>>> the best solution for these filesystems would be either to add new syscall
>>> int is_hardlink(char *filename1, char *filename2)
>>> (but I know adding syscall bloat may be objectionable)
>> i
Jeff Layton wrote:
> Benny Halevy wrote:
>> It seems like the posix idea of unique doesn't
>> hold water for modern file systems and that creates real problems for
>> backup apps which rely on that to detect hard links.
>>
>
> Why not? Granted, many of the
Arjan van de Ven wrote:
>> It seems like the posix idea of unique doesn't
>> hold water for modern file systems
>
> are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
> and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the world, esp
Trond Myklebust wrote:
> On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
>> Trond Myklebust wrote:
>>>
>>> On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
> BTW. how does (or how should?) NFS client deal with cache coherency if
> filehandles fo
Trond Myklebust wrote:
> On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote:
>> I sincerely expect you or anybody else for this matter to try to provide
>> feedback and object to the protocol specification in case they disagree
>> with it (or think it's ambiguous or
Trond Myklebust wrote:
> On Thu, 2007-01-04 at 12:04 +0200, Benny Halevy wrote:
>> I agree that the way the client implements its cache is out of the protocol
>> scope. But how do you interpret "correct behavior" in section 4.2.1?
>> "Clients MUST use fi
Nicolas Williams wrote:
> On Thu, Jan 04, 2007 at 12:04:14PM +0200, Benny Halevy wrote:
>> I agree that the way the client implements its cache is out of the protocol
>> scope. But how do you interpret "correct behavior" in section 4.2.1?
>> "Clients MUS
Jens Axboe wrote:
> @@ -323,13 +324,17 @@ static int __dma_map_cont(struct scatterlist *sg, int
> start, int stopat,
> {
> unsigned long iommu_start = alloc_iommu(pages);
> unsigned long iommu_page = iommu_start;
> - int i;
> + struct scatterlist *s;
> + int i, nelems;
>
Jens Axboe wrote:
> It's a subsystem function, prefix it as such.
Jens, Boaz and I talked about this over lunch.
I wonder whether the crypto code must use your implementation
instead of its own as it needs to over the sglist, e.g. for
calculating iscsi (data) digest.
The crypto implementation of
this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Benny Halevy
Panasas Inc.
Accelerating Time to Results(TM) with
Jens Axboe wrote:
> On Thu, May 10 2007, Benny Halevy wrote:
>> Jens Axboe wrote:
>>> It's a subsystem function, prefix it as such.
>> Jens, Boaz and I talked about this over lunch.
>> I wonder whether the crypto code must use your implementation
>> i
this fix?
>From b91b9cffd8bbb727c6480dfb18f79655806237e6 Mon Sep 17 00:00:00 2001
From: Benny Halevy <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 10:41:31 +0300
Subject: [PATCH] fix usb_serial_put synchronization
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
---
drivers/usb/seri
Jens Axboe wrote:
> On Thu, May 10 2007, Benny Halevy wrote:
>> @@ -411,12 +406,13 @@ int gart_map_sg(struct device *dev, struct scatterlist
>> *sg, int nents, int dir)
>> boundary and the new one doesn't have an offset. */
>>
Jens Axboe wrote:
> On Mon, May 21 2007, Jens Axboe wrote:
>> On Fri, May 18 2007, Badari Pulavarty wrote:
>>> On Fri, 2007-05-18 at 09:35 +0200, Jens Axboe wrote:
On Thu, May 17 2007, Badari Pulavarty wrote:
> On Thu, 2007-05-17 at 08:27 +0200, Jens Axboe wrote:
>> On Wed, May 16 2007
Andy, Pete, this patch also causes our test machines to hang hard during boot.
x86_64 smp kernel, single cpu Athlon 64 machine,
cpuinfo below.
Benny
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 79
model name : AMD Athlon(tm) 64
Jens Axboe wrote:
> +#define sg_is_chain(sg) ((unsigned long) (sg)->page & 0x01)
> +#define sg_chain_ptr(sg) \
> + ((struct scatterlist *) ((unsigned long) (sg)->page & ~0x01))
> +
> +/*
> + * We overload the meaning of ->page for sg chaining. If the LSB is
> + * set, the page
On Sep 17, 2007, 2:57 +0200, shinkoi2005a <[EMAIL PROTECTED]> wrote:
> Hi, all
>
> I have a question about printk format.
>
> Can printk format use "%4.4s"?
Yes it can.
The precision part of the format determines the max number
of characters to copy from the string.
The 4 byte signature array mi
On Sep 27, 2007, 18:46 +0200, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Sep 2007 01:38:27 +0900
> FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
>> This patch is for Jens' block tree (sg chaining branch).
>>
>> I don't have the hardware but this looks like a bug.
>>
>> ---
>> From: FUJ
On 02/13/2014 07:59 PM, Boaz Harrosh wrote:
> On 02/10/2014 11:57 AM, Benny Halevy wrote:
>> Tonian is now Primary Data.
>>
>
> Benny hi
>
> Do you need a push from my tree?
Yes please. Makes most sense.
Benny
>
> Boaz
>
>> Signed-off-by: Benny H
Tonian is now Primary Data.
Signed-off-by: Benny Halevy
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6a6e4ac..b42174d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6336,7 +6336,7 @@ F:drivers/net/wireless/orinoco
AINERS b/MAINTAINERS
> >> index 1bb06c5f7716..28dd83a1d9e2 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -9418,10 +9418,6 @@ F:drivers/net/wireless/intersil/orinoco/
> >>
> >> OSD LIBRARY and FILESYSTEM
> >> M: Boaz
68 matches
Mail list logo
