Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
s well. This (compile, and test thoroughly) is *not* a waste of time. It prevents you wasting everyone else's time, and it ensures that at least you have some assurance that the code you've written works properly. Anything else is just lazy and sloppy, and (quite rightly), nobody wants code by lazy, sloppy programmers in the kernel. > Please stop telling me I can do this due to a few mistakes that you > and the other developers are fucking over doing. It's not "a few mistakes". You've made a cock-up in pretty much every single patch I've seen from you. These are sometimes logical errors like this one -- a few moments thought should have told you that the change wasn't actually fixing anything. More often, you're demonstrating *obviously* that you have absolutely no idea about what the code you've changed should be doing, or what the effect of the change you've made actually is. Many people have tried to tell you, with varying degrees of helpfulness, verbosity and rudeness, where you are going wrong, and what things you need to be doing to make yourself a better developer, and you have pretty much universally ignored them. The reason that you are being told that you should work on some userspace project is because the complexity of the code-base is typically lower, there's less effort involved in understanding the code, and the developers are sometimes less finicky about code quality (so you can make more mistakes without people getting cross about it). This would all make it easier for you to get practice on a large multi-developer project. Note that doing so would still mean that you have to compile and test all your changes before you submit them to the developers. You don't get out of doing that at all. In short, the "work" you are doing here on the kernel is appallingly substandard, and you are giving no indication that you are learning anything from the people trying to help you. This is why people are getting angry. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You shouldn't anthropomorphise computers. They really --- don't like that. signature.asc Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
On Sun, Aug 03, 2014 at 01:30:44PM -0400, Nick Krause wrote:
> On Sun, Aug 3, 2014 at 8:28 AM, Sergei Shtylyov
> > On 03-08-2014 6:56, Nicholas Krause wrote:
> >
> >> This changes the ifdef statement in sg_set_bg to !CONFIG_DEBUG_SG in
> >> order
> >> to avoid a bug with xhci dequence/enquence functions.
> >
> >
> >dequeue/enqueue?
> >
> >
> >> Signed-off-by: Nicholas Krause
> >> ---
> >> include/linux/scatterlist.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> >> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> >> index adae88f..62de7b3 100644
> >> --- a/include/linux/scatterlist.h
> >> +++ b/include/linux/scatterlist.h
> >> @@ -111,7 +111,7 @@ static inline struct page *sg_page(struct scatterlist
> >> *sg)
> >> static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
> >> unsigned int buflen)
> >> {
> >> -#ifdef CONFIG_DEBUG_SG
> >> +#ifdef !CONFIG_DEBUG_SG
> >
> >
> >Didn't you mean #ifndef instead? I guess you didn't even try to
> > build-test this.
> >
> >
> >> BUG_ON(!virt_addr_valid(buf));
> >> #endif
> >> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
> >
> >
> > WBR, Sergei
> >
> I am going to stay around and learn more but am going to check my
> patches better as this is
> my fault.
This is something like the fourth time you've said this, and you
still haven't managed to do it. :(
Compile the code. Every. Single. Time.
Test the code. Every. Single. Time.
Not optional, not negotiable.
Hugo.
> Regards Nick
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- You stay in the theatre because you're afraid of having no ---
money? There's irony...
signature.asc
Description: Digital signature
Re: BTRFS doesn't handle USB device disconnect
On Wed, Dec 11, 2013 at 11:03:09AM -0500, Alan Stern wrote: > On Tue, 10 Dec 2013, Sarah Sharp wrote: > > > In order to stress test the uas driver (next-gen USB storage driver), I > > decided to run some tests with a USB 3.0 storage device with four 10GB > > partitions: BTRFS, ext3, ext4, and fat32. > > > > It seems that BTRFS doesn't handle unexpected USB disconnect very well. > > Is that expected behavior? It's something that's been known about for a while, but is clearly undesirable behaviour. I don't think anyone with the detailed knowledge of the FS code has investigated in enough depth to get to the point of proposing patches. I suspect it's just not shown up with enough disastrous consequences to bubble to the top of the stack of things to fix yet. I think we're still at the point of "you can use USB if you like, but don't be surprised if, sometimes, Bad Things happen when the bus disconnects briefly". The problems you show below do look quite like the kind of things we've seen btrfs doing on USB disconnects, so on only this evidence I wouldn't be quick to point any fingers at the USB layer (unless other filesystems corroborate the behaviour). Hugo. (I'm not a btrfs developer, but I do a reasonable amount of first-line support for it on IRC and linux-btrfs; we see these things every week or two). > > The BTRFS partition was created on an Ubuntu 13.10 system, with > > btrfs-tools version 0.19+20130705-1. > > > > On 3.12-rc6, if all partitions are mounted, and I yank the USB cable, > > the BTRFS filesystem still shows up as mounted. If I yank it multiple > > times, sometimes it's listed twice when the device is disconnected: > > > > /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > > > Sometimes (but not always) when I plug it back in, I can get /dev/sdc3 > > listed twice: > > > > /dev/sdb3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e4 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e42 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc1 on /media/sarah/ext3-part type ext3 > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc2 on /media/sarah/ext4-part type ext4 > > (rw,nosuid,nodev,uhelper=udisks2) > > /dev/sdc4 on /media/sarah/fat32-part type vfat > > (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2) > > /dev/sdc3 on /media/sarah/9f21ef28-0eac-4736-9964-db5378b877e41 type btrfs > > (rw,nosuid,nodev,uhelper=udisks2) > > On 3.13-rc1, the btrfs partion from the disconnected USB device > > continues to be listed as mounted. Yanking the cable produces some > > additional oops messages. It also produced a couple hard-hangs. > > Unfortunately, I didn't capture the dmesg during the hard-hangs, so I > > can't tell for sure which driver is to blame (uas, btrfs, or xhci). > > Does this happen with usb-storage instead of uas? > > What about with ehci-hcd instead of xhci-hcd? > > And just to be exotic, what about with dummy-hcd and the uas or > g_mass_storage gadget driver? -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- UNIX: British manufacturer of modular shelving units. --- signature.asc Description: Digital signature
