On Sat, Jul 20, 2019 at 4:05 PM James Bottomley
wrote:
>
> Is that a Reviewed-By or Tested-by? If so we can slide it into one of
> the -rc candidates.
So I can't really test it. Also, I replied to the first version of the
patch, there was a better series of four patches.
I tried to look for the
On Tue, Jun 4, 2019 at 2:30 AM Hannes Reinecke wrote:
>
> Gcc-9 complains for a memset across pointer boundaries, which happens
> as the code tries to allocate a flexible array on the stack.
> Turns out we cannot do this without relying on gcc-isms, so
> this patch converts the stack allocation in
On Tue, Jun 4, 2019 at 2:30 AM Hannes Reinecke wrote:
>
> Gcc-9 complains for a memset across pointer boundaries, which happens
> as the code tries to allocate a flexible array on the stack.
> Turns out we cannot do this without relying on gcc-isms, so
> this patch converts the stack allocation in
On Wed, Jun 5, 2019 at 12:39 AM Hannes Reinecke wrote:
>
> the fcoe vn2vn code is using the 'fc_rport_priv' structure as argument to its
> internal function, but is really expecting a struct fcoe_rport to immediately
> follow this one. This is not only confusing but also an error for new
> compil
On Mon, Jun 3, 2019 at 2:20 PM Linus Torvalds
wrote:
>
> In fact, what people *are* passing that thing is this:
>
> struct {
> struct fc_rport_priv rdata;
> struct fcoe_rport frport;
> } buf;
It is in fact worse than that.
Ye
So gcc-9 has a new warning about doing memset() across pointer boundaries.
We didn't have a lot of these things, and most of them got fixed
pretty quickly. The main remaining ones are oin FCoE, and look like
this:
In function ‘memset’,
inlined from ‘fcoe_ctlr_vlan_parse’ at drivers/scsi/fcoe/
On Fri, Nov 2, 2018 at 2:41 PM James Bottomley
wrote:
>
> This is a set of minor small (and safe changes) that didn't make the
> initial pull request plus some bug fixes.
Pulled,
Linus
On Fri, Oct 26, 2018 at 1:06 PM Nick Desaulniers
wrote:
>
> Is removing a filesystem considered a userspace breakage?
Yes - if a user notices.
The key word is *USER*.
Note that it's not "user space". It's not about _programs_ noticing,
it's literally about users and their workflows.
If some ch
On Fri, Oct 26, 2018 at 11:32 AM Nick Desaulniers
wrote:
>
> + Linus
> I'm not about the process of removing code from the kernel. Doesn't
> that violate the "thou shalt not break userspace" rule?
The only thing that breaks the "thou shalt not break userspace" rule
is fairly simple: things that
On Wed, Oct 24, 2018 at 3:59 AM James Bottomley
wrote:
>
> This is mostly updates of the usual drivers: [...]
Hmm. No diffstat?
The shortlog matches, but I really prefer seeing what the diffstat is
too and confirm that part.
Anyway, pulled,
Linus
On Mon, Oct 22, 2018 at 3:39 PM Dominik Brodowski
wrote:
>
> These are just a few odd fixes and improvements to the PCMCIA core
> and to a few PCMCIA device drivers.
Pulled,
Linus
On Wed, Apr 18, 2018 at 1:12 AM, Martin Wilck wrote:
>
> No, it doesn't (gcc 7.3.0). -> https://paste.opensuse.org/27471594
> It doesn't even warn on an expression like this:
>
> #define SIZE (1<<10)
> static int foo[ilog2(SIZE)];
Ok, I think this is the "random gcc versions act differently"
On Tue, Apr 17, 2018 at 4:35 PM, Martin Wilck wrote:
> Sparse emits errors about ilog2() in array indices because of the use of
> __ilog2_32() and __ilog2_64(),
If sparse warns about it, then presumably gcc with -Wvla warns about it too?
And if thats the case, then __builtin_constant_p() and a t
On Fri, Mar 23, 2018 at 9:25 AM, Bart Van Assche wrote:
>
> Have you considered to delete the WARN_ON_ONCE(!irqs_disabled()) statement?
> I think that check duplicates functionality that already exists in lockdep
> since lockdep is already able to detect spinlock use inconsistencies.
Please just
[ Adding PeterZ to participants due to query about lockdep_assert() ]
On Wed, Mar 21, 2018 at 8:38 AM, Arnaldo Carvalho de Melo
wrote:
>
> assert_spin_locked(&cmd->t_state_lock);
> - WARN_ON_ONCE(!irqs_disabled());
> + WARN_ON_ONCE_NONRT(!irqs_disabled());
Ugh.
Can't we just
On Wed, Mar 14, 2018 at 4:28 PM, James Bottomley
wrote:
> - vfree(ha->optrom_buffer);
> - kfree(ha->nvram);
> - kfree(ha->npiv_info);
> - kfree(ha->swl);
> - kfree(ha->loop_id_map);
> +
> + if (ha->optrom_buffer)
> + vfree(ha->optrom_buffer);
> +
On Sun, Mar 11, 2018 at 8:08 PM, Tobin C. Harding wrote:
>
> I think we are going to see a recurring theme here. MAX_MAILBOXES==64
> so this patch adds 1536 bytes to the stack on a 64 bit machine or 768
> bytes on a 32 bit machine.
Yeah, that's a bit excessive. It probably works, but one or two
On Thu, Feb 22, 2018 at 11:28 AM, James Bottomley
wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
When I pull that, I get something completely different from what you
claim I should get. Much bigger, and a lot more commits.
Hmm?
Dropped.
Linus
On Wed, Feb 14, 2018 at 12:28 PM, James Bottomley
wrote:
>
> Actually, can I cancel this. We've had a tree rebase between mine and
> Martin's which means I need to do a reset. I'll do that now and submit
> a new pull request next week.
Ok, dropped.
Linus
On Wed, Jan 31, 2018 at 9:42 AM, James Bottomley
wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc
Ok, now I did indeed get that
gpg: Can't check signature: unknown pubkey algorithm
because of your fancy new key. But making git use gpg2 indeed fixes
it, since I
On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck wrote:
>
> Here there isn't any reason for speculation. The core has the
> value of 'x' in a register and the upper bound encoded into the
> "cmp" instruction. Both are right there, no waiting, no speculation.
So this is an argument I haven't seen befor
On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams wrote:
>
> This series incorporates Mark Rutland's latest ARM changes and adds
> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> based approach is provided as an opt-in fallback, but the default
> mitigation, '__array_ptr', uses a
On Tue, Dec 12, 2017 at 9:22 AM, Martin K. Petersen
wrote:
>
> Arnd and Johannes fixed this up right away:
The commit you point to _is_ the probnlem. It does:
struct bfad_im_port_s *im_port = shost->hostdata[0];
which is utter bullshit crap.
Notice? It's assigning a pointer (im_port), from
On Tue, Dec 12, 2017 at 8:21 AM, James Bottomley
wrote:
>
> The most important one is the bfa fix because it's easy to oops the
> kernel with this driver, a regression in the new timespec conversion in
> aacraid and a regression in the Fibre Channel ELS handling patch. The
> other three are a the
On Tue, Nov 14, 2017 at 8:36 AM, James Bottomley
wrote:
>
> Hannes Reinecke (14):
> scsi: scsi_devinfo: Reformat blacklist flags
Ugh, that's just really ugly, but it's also wrong.
Just having long lines would probably have been much preferable, and
would mean that the commit that explains
On Mon, Nov 6, 2017 at 2:53 PM, Fengguang Wu wrote:
>
> The same dmesg happen to contain another libata related bug. Attached again.
> It's rare and in the error handling path, so unlikely a new regression.
>
> [ 49.608280] BUG: sleeping function called from invalid context at
> kernel/locking/
Looks good.
James, I expect I'll be getting this through the normal SCSI pulls..
Linus
On Fri, Sep 15, 2017 at 5:05 AM, Hannes Reinecke wrote:
> When calling SG_GET_REQUEST_TABLE ioctl that only a half-filled
> table is returned; the remaining part will then contain stale
> kernel m
On Tue, Apr 11, 2017 at 9:47 PM, Nicholas A. Bellinger
wrote:
> Hi Linus,
>
> Here are the outstanding target-pending bug-fixes for v4.11-rc7.
So I'm pulling this, but I'm getting real tired of this crap. We're
late in the rc's, I shouldn['t be getting pull requests of hundreds of
lines any more.
On Sat, Mar 18, 2017 at 7:08 PM, Nicholas A. Bellinger
wrote:
>
> Here are the target-pending fixes for v4.11-rc3 code.
So I'm very unhappy with how these patches were rebased or applied
just before the pull request.
I did my usual build test, but didn't notice how recent it all was
until after
On Wed, Mar 1, 2017 at 10:48 AM, Stephen Hemminger
wrote:
>
> Bad 4.11 initial INQUIRY buffer
> [1.218159] data: : 00 00 05 02 1f 00 00 02 4d 73 66 74 20 20 20 20
> [1.225654] data: 0010: 56 69 72 74 75 61 6c 20 44 69 73 6b 20 20 20 20
> [1.242930] data: 0020: 31 2e 30
On Sat, Feb 18, 2017 at 11:15 PM, Al Viro wrote:
>
> AFAICS, the minimal fix would be something like this:
Applied, along with getting rid of the BUG_ON() that made this bug
much worse than it would have been without it.
Linus
On Tue, Jan 31, 2017 at 7:41 AM, James Bottomley
wrote:
>
> It is a kernel bug and it should not be user triggerable, so it should
> have a warn_on or bug_on.
Hell NO.
Christ, James, listen to yourself. What you are basically saying when
you say it should be a BUG_ON() is
"This shouldn't happe
On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley
wrote:
>
> Can we compromise on "try not to revert a fix ...".
No.
It's about timing, and about how serious the regression is.
For example, if this happened in rc7, I would have reverted
immediately. No questions asked.
In this case, the "fix"
On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley
wrote:
>
> We're not reverting a fix that would cause regressions for others.
Oh HELL YES we are.
The rule is that we never break old stuff. Some new fix that fixes
something that never used to work, but breaks something else, gets
reverted very a
On Sat, Jan 7, 2017 at 6:02 PM, Johannes Weiner wrote:
>
> Linus? Andrew?
Looks fine to me. Will apply.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
On Fri, Dec 23, 2016 at 2:00 AM, Christoph Hellwig wrote:
>
> From: Christoph Hellwig
> Date: Fri, 23 Dec 2016 10:57:06 +0100
> Subject: virtio_blk: avoid DMA to stack for the sense buffer
>
> Most users of BLOCK_PC requests allocate the sense buffer on the stack,
> so to avoid DMA to the stack c
On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote:
>
> There may be deeper issues. I just started running scalability tests
> (e.g. 16-way fsmark create tests) and about a minute in I got a
> directory corruption reported - something I hadn't seen in the dev
> cycle at all.
By "in the dev cycle
Hi,
On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner wrote:
> On Fri, Dec 16, 2016 at 10:59:06AM -0800, Chris Leech wrote:
>> Thanks Dave,
>>
>> I'm hitting a bug at scatterlist.h:140 before I even get any iSCSI
>> modules loaded (virtio block) so there's something else going on in the
>> current me
These were all garbage,
Not only is the "From" name bogus ("root"), but they all got marked as
spam because you didn't use the right smtp server, and they don't have
the proper broadcom DKIM hashes.
Please fix your setup.
Linus
On Thu, Dec 1, 2016 at 11:10 AM, Sasikumar Chan
On Sat, Sep 24, 2016 at 8:27 AM, James Smart wrote:
>
> add u64 number parser
>
> Prior patch revised to use kasprintf.
> Modified match_number to use kasprintf as well
Why would you do this? It's insane. kasprintf() is not the right thing
at all to use for anything like this. It appears that you
On Tue, Jul 5, 2016 at 9:30 AM, Josh Boyer wrote:
> On Wed, Jun 22, 2016 at 11:57 AM, Quinn Tran wrote:
>>
>> - if (rsp->msix->cpuid != smp_processor_id()) {
>> + if (rsp->msix && (rsp->msix->cpuid != smp_processor_id())) {
>
> Did this wind up going into an official commit somewhere?
On Thu, Jun 23, 2016 at 9:13 AM, Quinn Tran wrote:
>
>
> QT: setting up the interrupt vector does not mean the interrupt starts firing
> immediately.
Actually, it very much can mean that. If the interrupt can possibly be
shared, there is a very real possibility of it fiding immediately.
Now, wi
On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote:
> The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC
> macros.
This version now looks ok to me.
I do have a comment (or maybe just a RFD) for future work.
It does strike me that once we actually change over the inode t
On Mon, Jun 13, 2016 at 12:04 AM, Hannes Reinecke wrote:
>
> And we have been running the very patch in SLES for over a year now,
> without a single issue being reported.
Oh, ok. So it's not "all qemu kvm instances are broken", it was a very
unusual issue, and the patch has actually gotten wider
On Sat, Jun 11, 2016 at 12:41 PM, James Bottomley
wrote:
>
> The QEMU people have accepted it as their bug and are fixing it.
Of course they are. Somebody found a bug in their device model, I'd
expect nothing else.
But I'm not worried about qemu. I'm worried about all the other random
devices th
On Sat, Jun 11, 2016 at 12:41 PM, James Bottomley
wrote:
>
> It looks like there's a hole where the emulation should be for the VPD
> inquiry, which is what cause the whole hang up and never speak to us
> again problem.
So? What makes you think real hardware doesn't have those kinds of issues?
T
On Sat, Jun 11, 2016 at 11:54 AM, Linus Torvalds
wrote:
>
> Is there some reason to believe that the qemu CD-ROM emulation is the
> only one with this problem?
Side note:the one thing that makes the qemu cd-rom emulator "special"
is not that it's not real hardware: i
On Sat, Jun 11, 2016 at 11:09 AM, James Bottomley
wrote:
> Two current fixes: one affects Qemu CD ROM emulation, which stopped
> working after the updates in SCSI to require VPD pages from all
> conformant devices. Fix temporarily by blacklisting Qemu (we can relax
> later when they come into com
On Fri, Nov 20, 2015 at 12:57 PM, James Bottomley
wrote:
>
> It's done under the scan mutex, so there can only be one thread in that
> code at once.
Hmm. Looking at the call chain seems to confirm that.
But looking at the call chain I _also_ see that we have
scsi_free_host_dev() there, which see
On Fri, Nov 20, 2015 at 10:26 AM, James Bottomley
wrote:
>
> We can look at it, but the analysis shouldn't be correct. This device
> is the one we first used to issue the report lun scan. Either it's an
> existing device, or we created it specially for the purpose. If it's an
> existing one, th
On Fri, Nov 20, 2015 at 10:26 AM, James Bottomley
wrote:
>
> We can look at it, but the analysis shouldn't be correct.
Just take the five seconds to check the freeing path, please. The last
free is this:
> INFO: Freed in scsi_device_dev_release_usercontext+0x23d/0x2d7 age=4 cpu=0
> pid=1
> fr
[ I don't know if the original reporter ended up actually sending this
to the scsi list like Greg asked, so I'll forward it myself just in
case ]
There seems to be a very old use-after-free in the scsi code (git
blame says the lines around this area are from 2005 and 2008) that
kasan reports.
I'v
On Fri, Nov 13, 2015 at 11:55 AM, Nicholas A. Bellinger
wrote:
>
>> So just to make it really clear to people: if you ignore the reports
>> from linux-next, then I will damn well ignore you. Comprende? Fair is
>> fair.
>
> Would you accept an updated PULL request with Alexander's patch, or
> prefe
On Fri, Nov 13, 2015 at 1:59 AM, Nicholas A. Bellinger
wrote:
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git
> for-next
Ok, not only was this pull request late, it had a semantic conflict
that causes the end result to not compile.
You must have
What the hell is wrong with linux-scsi.org?
Your machine:
Date: Fri, 13 Nov 2015 02:00:11 -0800
linux-iscsi.org:
Received: from [192.168.1.69] ...
by linux-iscsi.org (Postfix) with ESMTPSA id 80B6822DA37;
Fri, 13 Nov 2015 09:55:48 + (UTC)
mx.google.com:
Received: f
On Thu, Sep 17, 2015 at 1:06 PM, Christoph Hellwig wrote:
>
> This was caused by my commit, and I already acked a patch from Junichi
> Nomura to fix which should land in your inbox ASAP.
Thanks,
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
th
On Fri, Sep 11, 2015 at 2:07 PM, Nicholas A. Bellinger
wrote:
> (RESENDING)
This is not a re-send as far as I'm concerned. I've not seen the
original. The last email I saw from you was from Aug 18, the subject
being "target fixes for v4.2-rc7".
I also don't think I saw this in my spam-box. The g
On Fri, Feb 20, 2015 at 3:23 PM, Nicholas A. Bellinger
wrote:
>
> 34 files changed, 1776 insertions(+), 1636 deletions(-)
> delete mode 100644 drivers/target/iscsi/iscsi_target_core.h
> delete mode 100644 drivers/target/iscsi/iscsi_target_stat.h
> create mode 100644 include/target/iscsi/iscsi_
On Sun, Jan 4, 2015 at 10:05 AM, Giel van Schijndel wrote:
> Especially since one very strange piece of code seems to be written in
> such a way that a NUL needs to be placed where a NUL is present already.
Actually, it's worse than that. This:
> len = snprintf(fname, 99, "%s", buf);
> -
On Sun, Aug 31, 2014 at 11:59 AM, Nicholas A. Bellinger
wrote:
>
> Note that these patches where originally intended for -rc1, but missed
> the merge window. They are mostly iser-target related bug-fixes, along
> with a few other very minor cleanups.
So this pull request was strictly speaking to
Al,
just checking - did you expect me to take this from the email, or are
you preparing a pull request?
Linus
On Mon, Jun 23, 2014 at 12:44 AM, Al Viro wrote:
>
> OK, here it is, hopefully with sufficient comments:
--
To unsubscribe from this list: send the line "unsubscribe linu
On Tue, Jun 10, 2014 at 1:25 PM, Nicholas A. Bellinger
wrote:
>
> That would work, or I can simply include a pointer to Stephen's patch in
> the target-pending PULL request after the vhost API changes are merged
> and Linus can apply himself..
Yes. That way I'll include it in the merge, and every
On Mon, Jun 2, 2014 at 1:08 PM, h...@infradead.org wrote:
>
> It's reverting a patch that just doesn't fix a problem fully, so the
> prime reviewer and the patch author decided to withdraw it. It won't
> cause any kind of problem during bisection.
If it isn't a particularly large patch and doesn
On Mon, Jun 2, 2014 at 12:33 PM, h...@infradead.org wrote:
>
> Linus has been very unappy about rebasing close to or in the merge
> window, and other subsystems generally revert patches that late in the
> cycle as well. I'd prefer to stick to that model, but if you and Linus
> prefer the rebase n
On Fri, Apr 25, 2014 at 3:49 PM, David Rientjes wrote:
>
> Hmm, I see why this is needed because of the scsi_put_command(cmd), but I
> think you need to do struct scsi_device *sdev = ACCESS_ONCE(cmd->device)
> instead to prevent gcc from messing with the code generation.
No, if gcc were to move t
On Fri, Apr 11, 2014 at 5:23 PM, Linus Torvalds
wrote:
>
> This has been the biggest (by far) merge window so far, afaik.
> Might as well take this too.
Actually, I take that "by far" back. In fact it's not even the biggest
one (yet). It looks like 3.10-rc1 was worse i
On Fri, Apr 11, 2014 at 11:20 AM, James Bottomley
wrote:
>
> I also don't see this in linux-next, unless I'm not looking in the right
> place, so it would be a bit of a risk adding it just before -rc1.
.. but it sounds like you're not against it? I'll pull it - in the
chaos that is 3.15-rc1, this
On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov wrote:
>
> Yes, it seems that it actually needs > 30 secs. It spends most of the time
> (30.13286 seconds) in [..]
So how about taking a completely different approach:
- just say that waiting for devices in the module init sequence for
over 30 sec
On Tue, Feb 18, 2014 at 4:03 PM, Russell King - ARM Linux
wrote:
>
> Almost, but not quite. If we're going to avoid u64, then dma_addr_t
> woudl be the right type here because we're talking about DMA addresses.
Well, phys_addr_t had better be as big as dma_addr_t, because that's
what the resourc
On Mon, Feb 17, 2014 at 3:46 PM, Russell King wrote:
>
> One fix touches code outside of arch/arm, which is related to sorting
> out the DMA masks correctly. There is a long standing issue with the
> conversion from PFNs to addresses where people assume that shifting an
> unsigned long left by PA
On Thu, Jan 16, 2014 at 4:09 PM, Nicholas A. Bellinger
wrote:
>
> This change allows the percpu_ida tag allocator to optionally use
> interruptible sleep that iscsi-target expects, while still leaving the
> functionality + interface for existing percpu_ida consumers unchanged.
I'm not pulling thi
On Mon, Dec 23, 2013 at 10:24 AM, Oleg Nesterov wrote:
>
> However, the code above already has the users. Do you think it makes
> sense to add something like
No. I think it makes sense to put a big warning on any users you find,
and fart in the general direction of any developer who did that brok
On Mon, Dec 23, 2013 at 9:27 AM, Oleg Nesterov wrote:
>
> In short, is this code
>
> spinlock_t LOCK;
> unsigned long FLAGS;
>
> void my_lock(void)
> {
> spin_lock_irqsave(&LOCK, FLAGS);
> }
>
> void my_unlock(void)
> {
>
On Tue, Oct 29, 2013 at 1:06 PM, Dan Carpenter wrote:
> You and James are right. It should be checking against the sizeof().
> I will send a v2 tomorrow. Sorry about that.
Looking some more at this, I have to say that I absolutely detest
those aacraid structures. And I'm not sure that sizeof()
On Tue, Oct 29, 2013 at 12:10 PM, Dan Carpenter
wrote:
> If "fibsize" is zero then it leads to a ZERO_SIZE_PTR dereference when
> we dereference user_srbcmd.
Btw, these "ZERO_SIZE_PTR dereference" issues aren't about
ZERO_SIZE_PTR, they are about overrunning the allocations. The
ZERO_SIZE_PTR poi
On Wed, Oct 23, 2013 at 1:19 PM, James Bottomley
wrote:
>
> OK, so is the new driver exception gone then?
The new driver exception was about supporting new hardware, so we can
add things like new ID's etc (or even whole new drivers) later in the
development process than the merge window.
And any
On Wed, Oct 23, 2013 at 12:27 PM, James Bottomley
wrote:
>
> The patch is available here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
No it's not. "Already up-to-date.".
Also, even if it was, I'm not feeling the reason to pull it. "Cleanup
sprintf formatting of fir
On Sun, Sep 15, 2013 at 4:25 PM, James Bottomley
wrote:
> This patch set is a set of driver updates (megaraid_sas, fnic, lpfc,
> ufs, hpsa) we also have a couple of bug fixes (sd out of bounds and
> ibmvfc error handling) and the first round of esas2r checker fixes and
> finally the much anticipat
On Sun, Jun 23, 2013 at 12:09 AM, Ingo Molnar wrote:
>
> The spinning approach you add has the disadvantage of actively wasting CPU
> time, which could be used to run other tasks. In general it's much better
> to make sure the completion IRQs are rate-limited and just schedule. This
> (combined wi
On Fri, Dec 14, 2012 at 3:53 PM, Nicholas A. Bellinger
wrote:
>
> Here are the target updates for v3.8-rc1 merge window code. Please go
> ahead and pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git
> for-next
>
> Just a heads up that there is a minor merge con
On Sat, 8 Dec 2012, Mel Gorman wrote:
>
> Commit 8852aac2 (workqueue: mod_delayed_work_on() shouldn't queue timer on
> 0 delay) is causing the following boot failure for me. Found by bisection
> but no further analysis unfortunately until I get back home properly.
> I've added the relevant mainta
On Wed, Jul 25, 2012 at 7:10 PM, Jeff Garzik wrote:
>
> Thanks, so noted. I guess if the merge gets more complex than something
> easily described in an email, that implies that maintainers should do more
> cross-coordination and maybe a merge tree.
It's fairly rare. It happens mostly with the a
On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik wrote:
>
> What is the right course in when a post-merge change is needed?
Just describe the issue and the required change. Than I can just do it
as part of the merge, and now the whole series is bisectable,
including the merge itself.
Here's a (fairl
On Wed, Jul 25, 2012 at 3:26 PM, Jeff Garzik wrote:
>
> Even so, separately, it still needed that post-merge compile fix.
And that's yet another example of how *NOT* to do things.
If the merge has errors like that, then they should be fixed up in the merge.
Please. Don't do this. Let me merge s
On Wed, Jul 25, 2012 at 1:43 PM, Jeff Garzik wrote:
> On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
>> Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>> tags/upstream
>>
>
> Oh, I forgot to point out
On Sat, 23 Feb 2008, Jeff Garzik wrote:
>
> I know I am probably shooting myself in the foot here, since I am the original
> author of mvsas, but...
>
> Should we be adding new drivers during -rc?
I'm personally of the opinion that a new driver that doesn't add anything
but itself (ie no infr
On Thu, 7 Feb 2008, Andrew Morton wrote:
>
> Sob. Can we please merge "Convert SG from nopage to fault"?
Heh. I just took it directly then.
I think it's more of a VM patch than a SCSI patch anyway, so I don't think
you really should even have tried to push it through the SCSI tree.
It's not
On Thu, 7 Feb 2008, Harald Arnesen wrote:
>
> I'll try applying the patch to a freshly downloaded git-tree.
Ok, good.
> Shall I try another compiler? I have at least these two:
>
> gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
> gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I
On Thu, 7 Feb 2008, Harald Arnesen wrote:
> >
> > Can you do a
> >
> > make drivers/scsi/advansys.lst
> >
> > and see what it should be?
>
> Anyway, here it is, as an attachment.
Ok, I was wrong. The code really *does* compile to that insane
a3 14 00 00 00 mov%eax,
On Thu, 7 Feb 2008, Harald Arnesen wrote:
>
> OK, tried it. Another screen shot attached
> (I must really get another box to use as a serial terminal).
This oops decodes to
8b 44 24 10 mov0x10(%esp),%eax
8b 90 7c 02 00 00 mov0x27c(%eax),%edx
83 ea 54
On Tue, 5 Feb 2008, Bart Van Assche wrote:
>
> Results that I did not expect:
> * A block transfer size of 1 MB is not enough to measure the maximal
> throughput. The maximal throughput is only reached at much higher
> block sizes (about 10 MB for SCST + SRP and about 100 MB for STGT +
> iSER).
On Mon, 4 Feb 2008, Jeff Garzik wrote:
>
> Both of these are easily handled if the server is 100% in charge of managing
> the filesystem _metadata_ and data. That's what I meant by complete control.
>
> i.e. it not ext3 or reiserfs or vfat, its a block device or 1000GB file
> managed by a user
On Mon, 4 Feb 2008, Matt Mackall wrote:
>
> But ATAoE is boring because it's not IP. Which means no routing,
> firewalls, tunnels, congestion control, etc.
The thing is, that's often an advantage. Not just for performance.
> NBD and iSCSI (for all its hideous growths) can take advantage of the
On Mon, 4 Feb 2008, Jeff Garzik wrote:
>
> Well, speaking as a complete nutter who just finished the bare bones of an
> NFSv4 userland server[1]... it depends on your approach.
You definitely are a complete nutter ;)
> If the userland server is the _only_ one accessing the data[2] -- i.e. the
On Mon, 4 Feb 2008, Jeff Garzik wrote:
>
> For years I have been hoping that someone will invent a simple protocol (w/
> strong auth) that can transit ATA and SCSI commands and responses. Heck, it
> would be almost trivial if the kernel had a TLS/SSL implementation.
Why would you want authoriza
On Mon, 4 Feb 2008, J. Bruce Fields wrote:
>
> I'd assumed the move was primarily because of the difficulty of getting
> correct semantics on a shared filesystem
.. not even shared. It was hard to get correct semantics full stop.
Which is a traditional problem. The thing is, the kernel always
On Mon, 4 Feb 2008, Nicholas A. Bellinger wrote:
>
> While this does not have anything to do directly with the kernel vs.
> user discussion for target mode storage engine, the scaling and latency
> case is easy enough to make if we are talking about scaling TCP for 10
> Gb/sec storage fabrics
On Mon, 4 Feb 2008, James Bottomley wrote:
>
> The way a user space solution should work is to schedule mmapped I/O
> from the backing store and then send this mmapped region off for target
> I/O.
mmap'ing may avoid the copy, but the overhead of a mmap operation is
quite often much *bigger* th
On Sun, 4 Nov 2007, Jeff Garzik wrote:
>
> The end to CD-ROM polling... newer SATA ATAPI hardware will emit
> 'asynchronous notification' events when media is changed. This adds
> support.
I *really* didn't want to pull this.
Not only is it after the -rc1 period, but I also think you pushed
On Wed, 24 Oct 2007, James Bottomley wrote:
>
> OK, so it's no secret that I'm the last of the subsystem maintainers
> whose day job isn't working on the linux kernel. If you want a full
> time person, who did you have in mind?
Quite frankly, at least for me personally, what I would rather hav
1 - 100 of 116 matches
Mail list logo
